The five modules included within SSADM outline the life cycle comprising of a significant amount of both written and diagrammatical deliverables. Due to the scope of this development being a small not a large scaled project which SSADM is originally intended for, a number of these weren’t conducted, e.g. the entire Feasibility study, elements of the Requirements analysis, Requirements catalogue etc. This methodology does include a detailed thorough account correctly stated by author MIT Notes Home. (2007).
During the development of this project a number of fundamentals were brought to light, highlighting the impact of utilizing SSADM as a development Methodology that also applies to most development methodologies. Methodologies have the ability to identify tasks conducted within each module however they fail to recognize and state how developers use this information to progress from one stage another with regards to actually carrying out the analysis, design stages etc. This is evident as SSADM futures five modules but no explanation with regards to how developers interact between these.
Evolutionary approaches have lead towards organisations employing “commercial methodologies adapted for in-house use” also “methodologies which they claim to be unique to their organisation…” Avison, D. & Fitzgerald, G. (2006). If an alternative approach had to be identified for this scenario, an evolutionary approach tailored to Positively Vetted would have been employed. Embracing the techniques within SSADM, due to the fact that developers tend to use techniques which they are readily familiar with. Also the political viewpoint of the Effective Technical and Human Implementation of Computer-based Systems (ETHICS), a People-oriented methodology and SSM, an Organisational-oriented methodology, encompassing a socio-technical perspective. These three methodologies would effectively broaden the perspective for the developers, ensuring they are well equipped to develop solutions from a well informed viewpoint, if these methodologies are conducted suitably. In addition to this numerous stakeholders would have an input improving their overall understanding of what and why particular systems are to be developed.
7.0 EVALUATION OF THE APPLICATION OF THE CASE
Oracle Designer was employed as the CASE tool to develop Positively Vetted information system. This CASE tool provided useful functions as this enabled the development of Business Process Models, Function Hierarchies, Data Flow Diagrams and Logical Data Models, which in turn can be transformed into a relational database. This CASE tool was satisfactory to illustrate each input, process and output required however, to combine these elements to effectively generate the database caused immense difficulty. Due to the functionalities and limitations of this tool my capabilities were minimised hindering the creation of this database.
The limitations discovered were within the Repository Navigator, as it became somewhat difficult to remove incorrect imputed information without understanding and utilizing SQL script commands within SQL Plus 11g. Oracle Designer automatically generates SQL script commands from the information entered within the user interface. Also when errors occurred when attempting to generate the database, this CASE tool doesn’t provide sufficient information to help you determine the root cause of the problem.
Barclay, S. et al. (nd) identifies that a CASE tool is utilized for specific reasons, to “…ensure consistency… precision…speeds up development process… increases productivity…” With regards to ensuring consistency the author is correct as any conflicting details were flagged and highlighted to the developer, nevertheless experience utilizing this CASE tool identified that this doesn’t increase productivity as the number of errors detected take time to debug or even can result in developers having to restart the development if they aren’t aware of how to rectify the issues presented. Utilizing SQL Plus 11g could alternatively be a better solution, as developers tend to understand their commands imputed better than automatically generated syntax including irrelevant information.
To conduct this development utilizing an alternative CASE tool Select SSADM would have been employed, “…providing advanced features to support systems development activities using SSADM techniques.” Select Business Solutions, INC. (2003). Select SSADM has the ability to provide consistency, intelligent integrated modelling supporting numerous SSADM modules, techniques and application objects. In addition Select SSADM enhances project management and application quality, meeting business requirements, improving application independence whilst reducing errors. Select Business Solutions, INC. (2003).
8.0 CONCLUSION AND RECOMMENDATIONS
It’s vitally important when engaging within ISD that any methods, methodologies, approaches or frameworks are tailored to the particular organisation in question. As identified that many of these are not fit for purpose, as they require adaptation proven within chapter 6.0, to fit the organisations culture, system users and technological developments. Pertaining to SSADM and ISD, this methodology can be seen as too complex for quickly adapting organisations. This concern potentially is problematic with regards to the current demands/requirements of present day system users, which they place on system developers. To implement solutions quickly and effectively due to the fast paste revolutionising dynamic enviorments in which they are employed.
Methods, Methodologies, Approaches or Frameworks most importantly need to incorporate a mangerial concept to ensure projects are controlled continuously, reducing time/budget overruns resulting in project failures due to a substandard management style. Identified within the Standish Group Reoport highlighting “…almost a third experienced cost overruns of 150 to 200%...over one-third also experienced time overruns of 200 to 300%.” The Standish Group. (1995).
A number of ISD’s have been introduced into organisations under estimating the technological requirements of system users. Evident within the London Ambulance System Computer Aided Dispatch (LASCAD) scrapped in 1992, costing £2.5 Million and resulting in the deaths of atleast 20 individuals. Therefore ISD should be implemented in a way whereby solutions should be developed progressively, departmentally conducting thourough quality assurance and system testing. To define problems which can then be rectified before an entire operation is made live, this can be trialed in many ways for example through the use of a pilot study. However while conducting thourough on going testing problems can still go undetected present within the “…marriott and Hilton Hotels…failed reservation system…” Standish Group. (1995).
CASE tools have been identified to increase ISD, however only if the relevant most compatible tool is employed acknowledged within chapter 7.0. Nonetheless if developers were entirely comfortable utilizing a CASE tool, given their provided with the right amount of training, they most inevitably will display an improve level of performance with regards to productivity. Consequently these are the underlying factors organisations need to consider when employing a CASE tool for ISD.
Another fundermental issue highlighted no matter what methodology is used to develop a project, this is only as effective as the developers. “…the fact that it is people, not methods, who develop systems” Rowlands, B.H. (2005). With regards to their personal skills, knowledge and technical abilities applied. Therefore no matter how well suited a methodology is to a development, this isn’t the only factor determining development success. As methods-in-action are affected and influence by the Development context, Developers, Formalised methods & Roles of Methods acknowledge by Fitzgerald et al 2002.
On the other hand SSADM doesn’t take into account the ability of the developers, the organisations culture identified via the Development context and the Roles of Method. Therefore how well can this methodology address the needs of all system stakeholders?
9.0 REFERENCES
Anwar, S., Khan, O.A., Pirzada, U.T. & Shahid, N. (nd). Rational Unified Process. Journal Title.[Online]. Available from: http://ovais.khan.tripod.com/papers/Rational_Unified_Process.pdf [Accessed: 16th April 2009].
Avison, D. & Fitzgerald, G. (2006). Information Systems Development methodologies, techniques & tools. Maidenhead:McGram-Hill Education.
Avison, D.E & Fitzgerald, G. (2003). Where Now for Development Methodologies?. Communication of the ACM. 46(1) pp.79-82.
Barclay, S. et al. (nd). CASE TOOLS. [Online]. Available from: http://educ.queensu.ca/~compsci/units/casetools.html [Accessed: 19th April 2009]
Batty, P. et al. (1994). USE OF INTEGRATED CASE TOOL FOR GIS CUSTOMISATION. Smallworld Systems LTD. 1(1) pp 852-859 [Online]. Avaliable from: http://libraries.maine.edu/Spatial/gisweb/spatdb/egis/eg94097.html [Accessed 20th April 2009].
Bowles, A.J. (1990). A note on the Yourdon Structured Method. Software Engineering Notes. 15(2) pp. 27.
Campos, P. (nd). User-Centered CASE Tools for User-Centered Information Systems. pp.1-1-
Database Journal. (2005). Making the Case for CASE Tools. [Online]. Available from: http://www.databasejournal.com/features/oracle/article.php/3525621/Making-the-Case-for-CASE-Tools.htm [Accessed 20th April 2009].
Fitzgerald, B., Russo, N.L. & Stolterman, E. (2002). Information Systems Development: Methods in Action. Maidenhead:McGram-Hill Education.
Grunner, S., Klopper, R. & Kourie, D.G. (2007). Assessment of a Framework to Compare Software Development Methodologies. ACM International Conference. 226(1) pp. 56-65.
Hutchings, T. (1996). Introduction to Methodologies and SSADM. [Online]. Available from: http://www.comp.glam.ac.uk/pages/staff/tdhutchings/chapter4.html [Accessed: 13th April 2009].
Ice Breaker web designs. (2002). Database Answers. [Online]. Available from: http://www.databaseanswers.com/modelling_tools.htm [Accessed: 20th April 2009].
Jarzabek, S. & Huang, R. (1998). CASE tools need to become more useful if they are to be applied to the practice of software production. The CASE for User-Centered CASE Tools. 41(8). pp. 93-94. [Online]. Available from: http://portal.acm.org/citation.cfm?id=280338&coll=&dl=ACM&CFID=15151515&CFTOKEN=6184618 [Accessed 10th April 2009].
Lambrou, N., Walkley, M., & Weaver, P. (2002). Practical Business Systems Development Using SSADM: A Complete Tutorial Guide. Harlow: Pearson Education Limited.
MIT Notes Home. (2007). Methodologies and the SSADM methodology Chapter 2. Lifecycles and development methods. [Online]. Available form: http://www.cs.uct.ac.za/mit_notes_devel/SE/Latest/html/ch02s07.html [Accessed: 20th April 2009].
Orlikowski, W.J. (1993). CASE Tools as Organizational Change:
Investigating Incremental and Radical Changes in Systems Development. Management Information Systems Quarterly Best Paper of 1993. 17(3) pp 1-32 [Online]. Available from: http://www.misq.org/archivist/bestpaper/misq93.html [Accessed 15th April 2009].
Rogerson, s. (nd). An ethical review of information systems development and the SSADM approach. [Online]. Available from: http://www.ccsr.cse.dmu.ac.uk/staff/Srog/teaching/ssadm.htm [Accessed: 19th April 2009].
Rowlands, B.H. (2005). Grounded Theorising Applied to is Research – Developing a Coding Strategy. AJIS. 12(2) pp. 121-133.
Select Business Solutions, INC. (2003). SelectSSADM. [Online]. Avaliable from: http://www.selectbs.com/adt/images/stories/datasheets/ds_Select_SSADM_a4.pdf [Accessed: 7th June 2009].
The Standish Group. (1995). Chaos Report. The Standish Group Report. 1(1) pp. 1-8.
Vessey, I. et al. (1992). Implications of the findings. Evaluation of Vendor Products: CASE Tools as methodology companions. 35(4). pp. 100-101 [Online]. Available from: http://portal.acm.org/citation.cfm?id=129860&coll=&dl=ACM&CFID=15151515&CFTOKEN=6184618 [Accessed 14th April 2009].
Yeates, D. & Wakefield, T. (2004). Systems Analysis and Design. Essex: Pearson Education Limited.
10.0 Bibliography
Avison, D. & Fitzgerald, G. (2006). Information Systems Development methodologies, techniques & tools. Maidenhead:McGram-Hill Education.
Fitzgerald, B., Russo, N.L. & Stolterman, E. (2002). Information Systems Development: Methods in Action. Maidenhead:McGram-Hill Education.
Lambrou, N., Walkley, M., & Weaver, P. (2002). Practical Business Systems Development Using SSADM: A Complete Tutorial Guide. Harlow: Pearson Education Limited.
Tudor, D.J. & Tudor, I.J. (1997) Systems Analysis and Design. London: MACMILLAN PRESS LTD.
Yeates, D. & Wakefield, T. (2004). Systems Analysis and Design. Essex: Pearson Education Limited.
Table 2.1-1
Appendix B: Process Model
Four processes were initially illustrated using the drawing tool Microsoft Word before a chosen CASE tool was selected. These diagrams are illustrated below.
Figure 1 – Process 1 Figure 2- Process 2
Process 1 illustrated within Figure 1 identifies that the client registration form provides the initial trigger which enables a client to signup with the branch to receive pet veterinary care. The next process involves the clients registration from being process, this information is then stored within the client record. Once the client’s information is safely electronically stored the registration form is then disposed of. The last process involves sending a welcome pack to the client to identify all the services provided at this verterinary practice.
Process 2 illustrated within Figure 2 identifies that when a client contacts their branch to book an appointment this provides the initial tigger which enables clients to book an appointment. Once the client calls their branch a convenient appointment is created illustrated by the next process, this information is then stored within the system. The last process enables the client to be provided the appointment details regarding their appointment.
Figure 3 – Process 3
Process 3 illustrated within Figure 3 identifies that when a client attends their appointment this provides the initial trigger which immediately leads to the creation of their invoice. Once their invoice is created the consoltation fee is then added. The next process involves the vet performing a diagnosis report and recording the treatment to be allocated. The next Process can involve three potential happenings.
The first potential happening after the diagnosis report is conducted could be Treatment Administered identified via the green colour scheme. Once the treatment has been administed the next process involves the vet recording this information. The next process will result in this information being used to update the client invoice regarding the treatment administered or prescribed . The next process will then result in the invoice being further updated if further treatment is required untill treatment is complete. If this is not necessary once the treatment is complete the invoice is then mark as Payment required and is then issued to the client convey within the last to green coded processes.
The second potential happening after the diagnosis report is conducted could result in a refferal identified via the blue colour scheme. Once the Client has been referred, the next step involves the branch contacting the outsourced specialist to book an appointment. The next process will involve the appointment being stored along with client details. The next process involves the client’s branch providing the outsourced specialist with the pet/diagnosis and treatment details. The next process will then involved the client being informed regarding their appointment details. When the client attends this appointment the next process involves the treatment administered. Once the treatment is given the next process involves the outsourced specialist sending a record back to the client’s branch identifying what the pet has received. The next process will then result in the invoice being further updated if further treatment is required untill treatment is complete. If this is not necessary once the treatment is complete the invoice is then mark as Payment required and is then issued to the client.
The third potential happening after the diagnosis report is conducted could result in the pet not requiring any necessary treatment identified via the orange colour scheme. The next process will then result in the invoice being recorded as Payment required and is then issued to the client.
Fig 4 – Process 4
Process 4 illustrated within Figure 4, identifies that when an invoice is issue to the client by the Branch Co-ordinator this provides a trigger to commence payment. The next process involves two potential happenings, either the client wouldn’t have paid within 14 days shown via the red colour scheme. Which then leads to a reminder being sent to the client every 14 days until they payment is processed. The next process will take place once the client has paid leading to the final process whereby their invoice will be filed for the next 5 years until deleted.
Or the next potential happening identifies that the client will pay within 14 days leading to the final process whereby their invoice will be filed for the next 5 years until deleted.
Appendix C: Context Diagram
Context Diagram can’t be constructed in Oracle designer therefor this has been done using the a drawing tool, Microsoft Word
Fig 5 – Context Diagram
All three external entities have been identified illustrating the different data flows moving in and out of Positively VETTED Veterinary System (PVVS) identified via the central box. There are two data flows present concerning the Royal College of Veterinary Surgeons Entity. The first is Treatment Price List illustrating that PVVT recieves this information from the Royal College of Veterinary Surgeons, whereby management utilise this to input Treatment prices. The second dataflow Price List Request illustrates that the system requests this information form Royal College of Veterinary Surgeons.
Seven data flows have been established for the Client entity. Reading from left to right firstly we have Invoice, this dataflow identifies when an invoice is issued to the client once payment is required. Secondly we have prescription, this identifies when a client is presented with a prescription for their pet. Thirdly we have Client Details, this identifies when a client receives their information pack once they have registered with their branch. Fourthly again we have Client Details, this identifies when a client initial registers providing information which is then processed by PVVS. Fifthly we have Appointment Details, this identifies when a client books an appointment which is processed by PVVS. Sixthly again we have Appointment Details, this identifies when a client’s appointment has been processed and then this information is then sent out to the client. Seventhly we have payment, this identifies when a payment is made regarding a particular client invoice by the client.
Five data flows are established for the Outsources Treatment Specialist entity. Reading from left to right firstly we have Referral Information Result dataflow, this identifies when the Outsource Treatment Specialist sends the listed treatments administered to the pet back to the branch after the pets appointment. Secondly we have the Pet Details dataflow, this identifies when the pet information is retrieved from the system and given to the Outsource Treatment Specialist before the pet’s appointment. Thirdly we have the Diagnosis Record dataflow, this identifies when this record is retrieve and sent to the Outsource Treatment Specialist which states the pet’s symptoms. Fourthly we have the Treatment Plan Record dataflow, this identifies listed treatment that are sent from the branch to the Outsource Treatment Specialist to clarify what the pet requires at their appointment with the Outsource Treatment Specialist. Fifthly we have the Appointment Availability dataflow, this identifies when an appointment is booked for a referred client and their pet.
Appendix D: DFD
Within Oracle Designer a DFD was developed illustrating how each entity, dataflow and data store are interlinked together to ensure information is filtered accordingly throughout PVVS. Two screen shots have been included of this dfd as the case tool wasn’t able to display this entire model, labelled Fig 1.6 & 1.7 located within appendix D.
Firstly the three external entities identified within the context diagram have been included to model all information flows taking place outside of PVVS. The three external entities include
- Client
- Outsourced Treatment Specialist
- Royal College of Veterinary Surgeons
Secondly seven processes were established which would be explained individually below
-
Process 1.1 labelled Register Client involves a number of happenings. The first dataflow labelled Client Details leading into the process from the External entity labelled Client identifies when the Branch Receptionist receives Client Registration Form. Process 1.1 conducted by the Branch Receptionist uses PVVS to process client registration details. From this process another data flow labelled Client Details leads out of the process to data store D1 Client Details. This identifies the store which client registration details are stored within. The last data flow within the process is also labelled Client Details, this identifies that the external entity labelled Client receives client registration details once they have been registered.
-
Process 1.2 labelled Place and Monitor Appointment involves a number of happenings. The first dataflow labelled Appointment Details leading into the process from the External entity labelled Client, identifies when the client contact their branch to book an appointment. Process 1.2 conducted by the Branch Receptionist uses PVVS to process the client’s appointment. From this process another data flow labelled Appointment Details leads out of the process to data D2 Appointments. This identifies the store which client appointment details are stored within. Another data flow labelled Appointment Details, leading out of the process external entity labelled Client, identifies PVVS proving clients with information regarding their appointment. Appointment Availability data flow is also established leading out of process 1.2 to the external entity Outsourced Treatment Specialist. This identifies where the branch books appointment for referred clients.
-
Process 1.3 labelled Diagnose and Allocate Treatment involves a number of happenings. Firstly the process requires information held within D2, so the VET can establish who this appointment is for. Secondly the Vet then performs the process by creating a diagnosis report and identifying the treatment to be allocated. The data flow labelled Diagnosis Details leading out the process identifies diagnosis details which are stored within D3 Diagnosis. The dataflow labelled Treatment leading out of the process identifies the treatment details which is then stored within D4 Treatment Plan. Another data flow present is Prescription, leading out of the process this identifies if a pet requires a prescribed treatment which is given to the external entity the client to give to the pet.
-
Process 1.4 labelled Process referral Details involves a number of happenings. Firstly this process requires information held within D1, D2 & D3 to generate client referral information. Identifying the treatment required, Diagnosis created and the Pet details. Once this process has been conducted these details are given to the Outsourced Treatment Specialist identified through the three data flows, Treatment Plan, Diagnosis Record and Pet Details, all leading towards the external entity Outsourced Treatment Specialist. Once the client attends the appointment the data flow labelled Referral Information Result, leading from the Outsourced Treatment Specialist to the process identifies where this document is then processed by the Branch Receptionist. The data flow labelled Update Treatment Plan identifies whereby the branch receptionist updates the clients treatment file from the information provided within the Referral Information Result,
-
Process 1.5 labelled Create Invoice involves a number of happenings. Firstly this process requires information stored within D1 & D4, data flow Treatment Plan and Client Details, identify this process acquiring this information regarding client details and treatment given to generate the invoice. Once the invoice has been generated this is then transferred identified by the dataflow Invoice leading out of the process into D1. All client invoices are temporally stored within the client details store up until payment has been made. Once the invoice has been the create the data flow Invoice, leading out of the process to the external entity client, identifies the Branch Co-ordinator issuing the client their invoice.
-
Process 1.6 labelled Process Payment identifies how PVVS knows when and what a client owes. The data flow Payment, identifies when the branch receptionist receives payment cash or credit from the client. I haven’t included a necessary from the process which should be labelled Issue Reminder; this is provided if a client doesn’t pay within 14 every 14 days until they pay. Another which should be present is Client details taken from store D1 leading into the process to determine client details. The dataflow payment, leading out of this process to D5 where payments are stored for 5years once paid, identifies when a client has paid.
-
Process 1.7 labelled Process Treatment Price includes three data flows. Treatment Price list data flow leading from the external entity Royal College of Veterinary Surgeons (RCVS) identifies the price list which Positively VETTED receive. This information is then process by the project management. The price list request data flow identifies when PVVS requests treatment cost from RCVS. Once these treatments are processed this information is stored within D4 Treatment Plan.
Appendix E: Entity Matrix Diagram
An entity event matrix was created to identify the potential relationships within the Logical Data Model (LDM). Crosses were entered where any potential relationships was identified.
From the Entity Matrix Diagram these entity relationships were established:
- A one-to-many relationship was established between the Client and Branch identifying that a Client belongs to one Branch, also that Branches can have many Clients
- A one-to-many relationship was established between Client and Invoice identifying that a Client can have many Invoices, also an Invoice only belongs to one client
- A many-to-many relationship was established between the Branch and Vet as a Branch can have many Vets and Vets can belong to many Branches stated within the case study
- A many-to-many relationship was established between the Branch and Outsourced Treatment Specialist identifying that a Branch can have many Specialist Providers and Specialist Providers can deal with many Branches
- A many-to-many relationship was established between Vets and Diagnosis Report as Vets can create many Diagnosis Reports and Diagnosis Reports can be written by many Vets
- A one-to-many relationship was established between the Treatment Plan and the Diagnosis Report as Diagnosis Reports can have many Treatment Plans but a Treatment Plan can only belong to one Diagnosis Report.
- A one-to-many relationship was established between the Treatment Plan and Vets as vets can prescribe many Treatment Plans but a Treatment Plan can only be prescribed by one Vet
- A one-to-many relationship was established between the Treatment Plan and Invoice as Invoices can have many Treatment Plans but a Treatment Plan can only belong to one Invoice
Appendix F: Logical Data Model
Logical Data Model (LDM)
An LDM also equivalent to an Entity Relationship Diagram (ERD) was created utilising the information present within the Entity Event Matrix. The 1st stage involved resolving the many-to-many relationship established within the Entity Event Matrix.
-
From Fig 1.5 within appendix F you can see that the Referred Patient Service entity was created as the linking entity between Branch and Outsourced Treatment Specialist. This entity in affect lists only the Outsourced Treatment Specialists in relation to a particular branch.
-
The Appointment entity was included to resolve the many-to-many relationship between Branch and Vet. Creating a relationship between Vet and Appointment, Branch and Appointment rather than Vet and a Branch.
-
The Treatment Plan entity was included to resolve the many-to-many relationship between Vet and Diagnosis Report. The Treatment Plan entity will indicate any treatments given to a particular pet during their appointment.
- All this information was displayed within Oracle Designer 2000
Fig 1.5
The second stage conducted was to determine the attributes within each enitity. Each entity was created either with a Primary/foreign or composite key depending on the information stored.
Where an entity attribute has been underlined this indicates this to be the primary key for the table. Where an astrix is present before the name of an attributes this identifies this to be a primary key from a related table. All Entities and Attributes are listed within table 2.1-2 within Appendix F
Table 2.1-2
Appendix G Entity Life History
Appendix H Research Portfolio
- Topic: Where Now for Development Methodologies?
Reference:
Avision, D.E. & Fitzgerald, G. (2003) Where Now for Development Methodologies?. Communications of the ACM. 46(1) pp.79-82.
Summary: This journal contains a brief history of systems development methodologies outlining methods deployed within the stated Pre-Methodology era based from 1960’s through to the 1970’s, highlighting the various stages and the purpose of the System Development Life Cycle (SDLC). During the Methodology era stated a number of emerging methodologies such as Structured, Data-oriented, Prototyping, Object-Oriented, Participative, Strategic and Systems approaches etc created for different types of systems development were mentioned. The Post-Methodology era commencing within the 1990’s stated controversy as to why some organisations deploy a methodology and others don’t due to practicality and productivity issues also high-lighting that certain developments require ad-hoc trial & error approaches.
Critical Evaluation
Trustworthiness: The authors have provided a coherent well structured paper publishes within ACM pinpointing evolutionary areas of systems development. The term methodology and approach has been utilized interchangagibly as the authors haven’t clearly distinguished between them. This may confuse readers if they aren’t aware or are unable to differentiate between two. The information within this article is supported through a number of references, somewhat increasing the integrity. In all this paper has been written in an opinionated fashion highlighting prior and new alternatives means for developing systems.
Usefulness: This paper provides a concise overview detailing the philosophy regarding the use of particular methodologies/approaches. Not only are the methodologies/approaches stated but the programmer’s former ideas and their business knowledge regarding project development. This paper isn’t useful as
thorough details aren’t provided and the clarity of the information is ambiguous.
Strengths: This paper provided a clear foundation for which to acquire further information on Methodologies and Approaches used within systems development
Weaknesses: To gain a thorough understanding into the methodologies/approaches mentioned the research was somewhat vague and lacked endorsements by means of example studies. The author’s opinion shaped this article from beginning to end.
- Topic: A Brief History of the Object-Oriented Approach
Reference:
Capretz, L.F. (2003). A Brief History of the Object-Oriented Approach. ACM SIGSOFT Software Engineering Notes. 28(2) pp. 1-10.
Summary: This paper contains an in-depth description of the Object-Oriented (O-O) paradigm and its approach defining the term utilizing literature from Rentsch, Pascoe, Robson, Nygarrd and Wegner. The derivatives of the Object-Oriented approach are identified, its use within programming languages, Office Information Systems, Systems Simulation and so forth. Background concepts such as Classes, Objects, Data abstraction in programming languages and frames are outlined and explained through example. A comparison between former programming languages such FORTRAN and Algol, Simula, Lisp, Smalltalk gearing towards present day languages, not so much C++ but that of JAVA analysing their evolution over time. O-O methods have been classified into three methodologies such as Structured Programming, Structured Analysis and Structured System Analysis (SADT) and Structured System Analysis and Design Methodology (SSADM) outlining the techniques used to developed models.
Critical Evaluation
Trustworthiness: This paper has been written in a structured comprehensible format published within ACM. The author has included a number of valid references to support the information included. Various new concepts were brought to light increasing my knowledge within this subject area. SADT and SSADM have been identified as O-O approaches when they are actually structured methodologies. Interchangeable terminology may somewhat confuse readers with little knowledge of the subject area.
Usefulness: This paper provides a useful incite regarding the methodologies employed within the Object-Oriented approach. Methodologies such as Structured Design, Structured Programming, Structured Analysis/Structured Systems Analysis and Structured Systems Analysis and Design are explained and the ways in which they should be adopted within systems development. CASE tools are also mentioned emphasizing their purpose to increase quality developments, increase productivity and facilitating systems documentation. As O-O methodologies were developed mainly for software, this paper identifies where the use of SADT and SSADM are necessary within systems development. This paper is useful as a wide range of topics are discussed.
Strengths: A detailed description of the Object-Oriented methodology is provided with supporting evidence from literature research findings. The literature was comprehensible and the distinction between the different methodologies was evident.
Weaknesses: Object-Oriented approaches are mainly aimed towards Software design, however Structured Systems Analysis and Design methodologies are utilize to implement many Information Systems.
- Topic: User-Centred CASE Tools for User-Centred Information Systems
Reference:
Campos, P. (nd). User-Centred CASE Tools for User-Centred Information Systems.
Summary: This paper refers to the development of CASE tools which facilitate and support all types of Information software System Building between developers/stakeholders. A researched approach has been applied to identify problems associated with prior CASE tools proposing User-Centred Development advancement for Next Generation CASE tools. CASE tools such as UML, Ideogramic UML, Software Design Board, CanonSketch, TaskSketch have been outlined and discussed. To conclude Pedro’s research recognizes a principal whereby high-quality behaviour models for developers and correct use of CASE tools leads to improved Information System (IS) Development.
Critical Evaluation
Trustworthiness: The author has provided a coherent well structured paper consisting of researched material providing a solution for modelling the behaviours and styles required for all stakeholders involved within IS development. Screen shots of this development have been provided outlining and explaining the eight areas of interest within the Workstyle Model for UCD (User-Centred Development). Prototype developments such as CanonSketch have brought their attention to both industry and academia. Prototypes are developed to be tested, however if these test are unsuccessful further developments are to be conducted until a successful approach is implemented. Whether this is the case is different in every development situation.
Usefulness: Pedros Campos has conveyed a comprehensible proposal whereby prototype developments have already been generated. Even though this approach is based from the Software engineering aspects of development, creating a CASE tool which involves all developers/stakeholders, the project itself, and a familiar concept to display the output, effectively can improve usability for each individual in question, improving developments. If a User-Centered CASE tool approach can be beneficial within a software environment, why can this not be just as effective within an IS development project?
Strengths: This paper proposes a method in which CASE tools can begin to advance and become more than a documentation tool, but a tool to aid development, demonstrate proposed developments of a project and also the developer’s style in doing so in which numerous stakeholders can appreciate, which effective provides an improved CASE tools for project design.
Weaknesses: The information discussed focuses on Software development
- Topic: Structured Methods: Systems Development Life-Cycle (SDLC)
Reference:
Weaver, P., Lambrou, N. & Walkey, M. (2002). Practical Business Systems Development Using SSADM. Harlow: Pearson Education Limited
Summary: A general overview is provided for the structured method Systems Development Life Cycle (SDLC) identifying how systems are developed and become operational. The authors identified that there are a number of variations to this approach indentifying an approach consisting of 6 stages, Strategic Planning, Feasibility, Analysis, Design, Implementation and Maintenance. An explanation is provided for each stage outlining the purpose within systems development.
Critical Evaluation
Trustworthiness: The authors have provided a brief opinionated explanation, no references are referred to, to support the factual information included within this account for the SDLC.
Usefulness: A comprehensible account for the SDLC has been provided outlining the stages of development. This is somewhat useful as this model provides a sequential process to accomplishing Information Systems Development. No critical appraisal has been included, therefore the success of this approach is debatable. Further research is required to gain a full insight into whether this is an acceptable approach for modern day systems developments
Strengths: The identification of SDLC
Weaknesses: The authors have provided a vague overview which tends to be mostly opinionated as statements are not supported by further research.
- Topic: Structured Method: Structured Systems Analysis and Design Methodology (SSADM)
Reference: Weaver, P., Lambrou, N. & Walkey, M. (2002). Practical Business Systems Development Using SSADM. Harlow: Pearson Education Limited
Summary: A brief history of SSADM is provided outlining its developments from 1981-2000. The structure is stated to consist of 5 stages: Feasibility Study, Requirements Analysis, Requirements Specification, Logical Systems Specification and the Physical Design. It has been stated that the techniques involved within SSADM are developed to tackle 3 crucial areas, the External Design, Conceptual Model & Physical Design which combines to create the Three-Schema Specification.
Critical Evaluation
Trustworthiness: The authors have provided a brief opinionated explanation, no references are referred to, to support the factual information included within this account for SSADM.
Usefulness: An informative approach provided a knowledgeable incite into the developments of SSADM. The authors clearly state that IS development consists of investing, Specifying then constructing and utilizing diagrammatical techniques such as, Dataflow Modelling, Logical Data Modelling and Entity Behaviour Modelling created to convey systematic functionalities. These models provide structure and clarity regarding data flows and data interaction between system users.
Strengths: This chapter specifies not only the order in which to construct IS development but the techniques involved to accomplish the tasks required.
Weaknesses: There is no evidence to identify the successfulness of this approach and what situations this approach is best applied to.
- Topic: Rapid Application Development
Reference:
Fitzgerald, B., Russo, N.L. & Stolterman, E. (2002). Informations Systems Development Methods in Action. Maidenhead: McGraw-Hill Education
Summary: A researched approach is employed to explain the origins of Rapid Application Development (RAD) identifying this as an assembly of tools and techniques acquired from previous methodologies focusing on the management ideologies to increase time/cost efficiency regarding project development. It is stated that RAD combines six main elements to achieve objectives, Active User Involvement, Small Empowered Teams, Frequently Delivered Products, Iterative Incremental Development, Top-Down Approach and Integrated Computer Assisted Software Engineering (I-CASE).
Critical Evaluation
Trustworthiness: The authors have provided a structured, coherent, comprehensible account for RAD. A number of references have been provided to support the information provided. Illustrative documentation has been included to demonstrate the process when employing the RAD approach. The literature within this book has been written to provide the bigger picture into Information Systems Development (ISD) enabling the reader to analyse and explore the process discussed. A critical stance has been undertaken to outline the above providing an analytical approach to convey this information.
Usefulness: Identifying and explaining the elements of RAD facilitates understand with regard to the concept of this process. The emphasis of group involvement and iteration are prominent within this process highlighting the benefits through researched findings. Solutions for Positively Vetted are to be produced individually, identifying key information from practice users and developing ideas with others. This is a potentially beneficial process to reduce errors/inaccuracies within developments.
Strengths: The factual approach taken evaluates each element identifying the purpose and argues the reason for RAD’s success and failures.
Weaknesses: How effective is RAD when designing and developing individual projects as this methodology is based upon group input, feedback and developments?
- Topic: The Dynamic Systems Development Method (DSDM) Rapid Application Development (RAD) Method
Reference:
Fitzgerald, B., Russo, N.L. & Stolterman, E. (2002). Informations Systems Development Methods in Action. Maidenhead: McGraw-Hill Education
Summary: The historical development of DSDM method derived from individuals interested in the RAD process. DSDM was founded by 16 individuals in 1994 evolving throughout a number years from version 1 through to version 4 released in 2002. DSDM consortium can now be located at , providing a range of resources for practitioners and academics or any individual with an interest in the organisation. DSDM’s illustrative spiral life-cycle consists of 5 stages Feasibility Study, Business Study, Functional model iteration, Design build iteration and Implementation.
Critical Evaluation:
Trustworthiness: The authors have provided a structured, coherent, comprehensible account for the DSDM method. A number of references have been provided to support the information provided. Illustrative documentation has been included to demonstrate the process when employing the DSDM method. The literature within this book has been written to provide the bigger picture into Information Systems Development (ISD) enabling the reader to analyse and explore the Method discussed. A critical stance has been undertaken to outline the above providing an analytical approach to convey this information.
Usefulness: Identifying and defining the stages of DSDM provides an understanding into the functionality of the method. The evaluation provided focuses on RAD and how effectively this is within an IS environment, therefore further research needs to be conducted to clarify DSDM’s ability.
Strengths: A foundation outlining DSDM was conveyed explaining the purpose and fundamental aspects involved.
Weaknesses: DSDM has potential downfalls highlighting omitted management and control factors and a negative impact on isolated project developments. Also RAD developments aren’t necessary suitable for all developments so therefore this is a factor which needs to be considered. An in-depth account of DSDM would have been more beneficial as an overview for this method.
- Topic: Towards Formalised End-User Participation in Information Systems Development:Bridging the Gap between Participatory Design and ISD Methodologies
Reference:
Pekkola, S., Kaarilahti, N. & Pohjola, P. (2006). Towards Formalised End-User Participation in Information Systems Development:Bridging the Gap between Participatory Design and ISD Methodologies. Proceedings of the ninth Participatory Design Conference. 1 pp. 21-30.
Summary: This paper identifies that there is a gap within Information Systems Development (ISD) methodologies and user participation. As research states ISD methodologies provide the development process but don’t address specifically how to involve the users. Soft Systems and Multiview Methodologies challenge this issue, however it has been found that philosophical explanations are provided which lack instructional detail for developers. A theoretical historical description of the ISD approach is explained outlining and evaluating methodologies such as Traditional life-cycle models, Prototyping approaches, Participatory design (PD), User-Oriented approaches and Human-Centered Systems Development Lifecycle (HCSDLC) Methodology.
Critical Evaluation
Trustworthiness: This paper has been written in a structured coherent comprehensible manner receiving recognition as this has been included within the ninth Participatory Design Conference held within 2006. Multiview has been defined as a methodology when actually this is a framework, again incorrect facts may somewhat confuse readers with little knowledge of the subject area. A number of references have been included to support the factual information included within this paper. Primary research has been conducted undertaking interviews, meetings, training sessions, workshops and observations of diverse work situations increasing the integrity of this paper through the findings within the studies conducted.
Usefulness: This paper provides incite as to why Multi-Methodological approaches to ISD development are important. Combining PD, Prototypes and Iterative systems development enables an indispensible source of information from users, knowledge is gained from further experience and repetitive processes improves current developments. This approach may prolong project development but provides knowledgeable, theoretical and practical developments.
Strengths: This paper highlights the importance from different aspects of methodologies/frameworks also the findings are supported through longitudinal research evaluating potential drawbacks and potential success factors to be further developed in the future from the creation of frameworks developed.
Weaknesses: As a mediator of this type of development how easy would this approach be to control within real life situations? also how well are you able to control developments of this kind?
- Topic: Soft Systems Methodology (SSM)
Reference:
Fitzgerald, B., Russo, N.L. & Stolterman, E. (2002). Informations Systems Development Methods in Action. Maidenhead: McGraw-Hill Education
Summary: SSM is said to have been created by Peter Checkland viewing ISD from an entirely different perspective. A philosophical approach is applied to understand the thought process encountered and experience acquired though research projects when developing systems.
Critical Evaluation
Trustworthiness: The authors have provided a structured coherent comprehensible account for SSM. A number of references have been provided to support the information provided. The literature within this book has been written to provide the bigger picture into Information Systems Development (ISD) enabling the reader to analyse and explore the Methodologies discussed. A critical stance has been undertaken to outline the above providing an analytical approach to convey this information.
Usefulness: SSM recognizes an alternative paradigm identifying the importance of individuals within an organisation and the complexity of human interaction. This approach does have a down side as it’s rarely adopted by organisations but utilized frequently in academic study. Identifying the importance of the development situation in question, the mind set of system developers and the actions taken is definitely an aspects of development which somewhat needs to be controlled.
Strengths: All findings are supported through research.
Weaknesses: SSM isn’t employed a great deal within the real world as systems are often developed without the input of systems users in some situation. For example BCU informative website for Stakeholders, Lecturers and Students has been developed without any user input to increase its success. This may be due to cost, time or complexity as a number of issues impact on the way in which systems are developed.
- Topic: DSDM (Dynamic Systems Development Method) and TOGAF (The Open Group Architecture Framework)
Reference:
DSDM Consortium. (year). DSDM (Dynamic Systems Development Method) and TOGAF (The Open Group Architecture Framework). [Online]. Availble from: http://www.opengroup.org/architecture/wp/dsdm/DSDM_Framework_and_TOGAF.pdf [Accessed: 27th February 2009].
Summary: This paper provides a brief isolated description of the DSDM and TOGAF methodology and framework. Identifying where products from both DSDM and TOGAF can be incorporated interchangeably within each other’s framework. This essentially identifies how principles and techniques from both frameworks can be combined together.
Critical Evaluation
Trustworthiness: This paper was written in structured, coherent, comprehensible format by the creators of this framework, the DSDM Consortium. There is no evidence of research or referencing to support the factual information included. This somewhat reduces the integrity of the information included, as the reliability can’t be challenged therefore its validity is somewhat debateable.
Usefulness: This paper isn’t particularly relevant or useful as a brief overview of the methodology is provided however a different perspective and approach is utilized to convey ideas.
Strengths: The strengths of this paper would be that it has been written in a consistent coherent format providing a structured comprehensible account.
Weaknesses: This paper has been written by the DSDM consortium and the creators of TOGAF, therefore a biased opinion with no further research to support this account provided.
- Topic: An Overview of Systems Design and Development Methodologies with Regard to the Involvement of Users and Other Stakeholders
Reference:
Singh, S. & Kotze, P. (2003). An Overview of Systems Design and Development Methodologies with Regard to the Involvement of Users and Other Stakeholders. Proceedings of SAICSIT. 1 pp. 37-47.
Summary: This paper provides various definition of Information System development identifying defects within the SDLC and O-O approaches. A number of methodologies and ISD techniques are discussed providing a comparisons and an essential focus evaluating Human-Computer Interaction (HCI) delving into the human element regarding systems development and how methodologies manages these aspects.
Critical Evaluation
Trustworthiness: A structured, coherent, comprehensible account of systems design and development methodologies regarding system users is provided, published within the SAICSIT. Opinions explaining the business environment and user interaction are supported through the use of diagrammatical illustrations and referenced research. Comparisons of systems development methodologies and techniques are concise and informative. Integrity is conveyed through the research provided commonalities between other papers found when explaining methodologies.
Usefulness: Outlining the Business Environment and its involvement with the development of IT projects is essential concept to grasp as humans thinking is behind all Information System development. Identifying that unification regarding users, stakeholders and IS developers is beneficial when developing relevant tailored Information Systems highlights that an approach within this category could be utilized when developing Positively Vetted.
Strengths: Decent explanations and comparisons are provided for methodologies discussed.
Weaknesses: Overall this is a well structured paper, however the literature displayed seems as though the authors have just collated research conducted by others and no personal contributions have been included.
- Topic: The fiction of methodological development: a field study of information systems development
Reference:
Nandhakumar, J. & Avison, D.E. (1999). The fiction of methodological development: a field study of information systems development. Information Technology and people. 12(2) pp. 176-190.
Summary: This paper provides the findings of a field study conducted to investigate Information System Development (ISD) in a large organisations. The authors takes onboard the view that Information System methodologies are more so employed to give the impression that a development is under control, also identifying there impracticality when handling developments within a dynamic environment. ISD processes are discussed identifying that within new methodologies they are technology cantered and techniques utilized are driven by software CASE tools. Multiview has been mentioned as a methodology consisting of a combination of methodologies which could potential be used to develop IS to overcome drawbacks which other methodologies may have acquired. The authors also discuss the implications of ISD methodologies
Critical Evaluation
Trustworthiness: This paper has been written in a structured, coherent, comprehensible format, published by the Information Technology & People. The authors have supported their opinions through findings discovered from a researched perspective, identifying arguments and issues which have arisen. This included elements of critical analysis when IS development processes were being appraised. Multiview again has been identified as a framework which may confuse readers with little knowledge of the subject area. A number of valid references have been included to support the information present within this paper.
Usefulness: Information regarding the Multiview framework paper wasn’t of much use. However this paper identifies the flexibility of this framework when employed within real life situations.
Strengths: There was supportive evidence to reinforce the information stated
Weaknesses: No clear methodology provided to utilise within ISD.
- Topic: A further exploration into information development: the evolution of Multiview2
Reference:
Avison, D.E., Wood-Harper, A.T., Vidgen, R.T. & Wood, J.R.G. (1998). A further exploration into information development: the evolution of Multiview2. Information Technology and people. 11(2) pp. 124-139.
Summary: The purpose of this paper is to describe and evaluate the Multiview Methodology. A detail account of Multiview1/2 are provided outlining the motive behind this methodology. Methodologies such as SSADM, Yourdon Systems Modelling and object-Oriented are present stating that these approaches incur different paradigms leading towards the developments of further methodologies.
Critical Evaluation
Trustworthiness: This paper has been written in a structured, coherent, comprehensible format, published within the Information Technology & People. A number of reference have been provided to support the explanation of the Multiview frame. This paper has identified Multiview as a methodology, again this may confuse readers who don’t have much knowledge within this subject area. This paper has been written in an information style supportive of this approach.
Usefulness: Multiview a Soft Systems framework provides a different perspective when developing Information Systems. Acknowledging Human activity, Human-Computer Interface, Technical and socio-Technical aspects of development as issues regarding these topics also impact on IS development.
Strengths: A detail account of this framework has been provided identifying the evolutionary development.
Weaknesses: As this paper has been written in favour of this framework criticism have been limited providing a bias opinion.
-
Topic: Evaluating of selecting a suitable Information Systems Development Methodology: An Investigation of the use of Methods within Information Systems Development Projects
Reference:
Fitzgerald, B. & Kiely, G. (2005). An Investigation of the use of Methods within Information Systems Development Projects. The Electronic Journal on Information Systems in Developing Countries. 22(4) pp. 1-13.
Summary: The purpose of this paper is to investigate whether the proposed criticisms of methodologies deployed within Information Systems Development (ISD) projects can be supported through their use today when applied to various diverse organisations. Practitioner’s selected methods then their views of these methods were further discussed. Studies were conducted to identify the above issues, which were then presented and analysed. It became evident that approaches required adaptation when applied to developments as no organisation or project is the same, as they are all unique in their own right hence the need for modification.
Critical Evaluation
Trustworthiness: A structure, coherent, comprehensible paper, published by The Electronic Journal on Information Systems in Developing Countries has been provided. A researched approach has been conveyed identifying the opinions of a number of researchers drawn from prior investigations through the use of valid referenced material.
Usefulness: Individual methodologies were not discussed but an overview of the categories in which they are grouped were discussed. This paper has been very useful as it clearly highlights where the problems may have began with methodologies and why IS developers are still facing these problems today. Structured and O-O methods were originally developed for mathematical and technical engineering practices, within a considerably different environment then when they were implemented. For this reason, how relevant are these approach today? within the dynamic environments in which we operate.
Strengths: The identification as to why problems are arising when choosing a development methodologies strengthened the arguments within this paper. Issues such as Inflexibilities, outdated, fundamental concepts unsuited to the current environment, Dissimilarities to engineering and scientific studies, Wet/Dry, Contingency Approach facilitated my understanding as to why certain approaches may have adverse affects on ISD.
Weaknesses: This papers focus was based on the negative aspects of ISD methodologies.
- Topic: A case for Soft Systems Methodology. Information Analysis and Information Systems Evaluation During Organisational Change
Reference:
Winklhofer, H. (2002). A case for Soft Systems Methodology. Information Analysis and Information Systems Evaluation During Organisational Change. ECIS. 6(8) PP. 303-311.
Summary: This paper describes research undertaken for a Ph.D Project, identifying the benefits of applying a Soft Systems Methodology (SSM) to analyse information, evaluating an IS project deployed throughout change within an organisation. A suitable framework was provided to tackle this complex situation regarding the relationship between Information Systems Development and the organisation, where roles were ill-defined and political tension was rife. SSM was utilized to determine the necessary organisation requirements and to implement this projects, discussing the various difficulties encountered.
Critical Evaluation
Trustworthiness: This tends be an opinionated paper supported by various valid referenced literature. This paper is very much in favour of SSM as it explains an instance in which SSM was effective. Through reading a number of sources SSM are often used to tackle social, political issues which arise within IS development. This paper reinforces these views by applying this theory to a case study increasing the integrity as the theoretical knowledge explained was proven.
Usefulness: This paper provides a detailed case study outlining why SSM was an appropriate methodology to conduct this IS development. This paper has been written in a structured, coherent, comprehensible format enabling understanding to be drawn from the topic discussed.
Strengths: A brief outline of the seven stages involved within SSM was explained distinguishing why this framework was employed. This aspect assisted with my understanding of the framework and its purpose. The application of this framework relates to the motive behind its use within the case study, as restructuring and new user required are to be identified and implemented.
Weaknesses: SSM has been categorised as group when there are a number of SSM.
- Topic: Selecting a Development Approach
Reference:
Centres for MEDICARE & MEDICAID Services. (2005). Selecting a Development Approach. [Online]. Available from: http://www.cms.hhs.gov/SystemLifecycleFramework/Downloads/SelectingDevelopmentApproach.pdf [Accessed: 27th February 2009].
Summary: This paper provides a brief overview outlining the Methodology, Framework Type, Basic Principle and In-depth listing of Strengths and Weaknesses and the Situations where these would be most appropriate.
Critical Evaluation
Trustworthiness: This paper has been written in structured manner providing a comprehensible document. Reference access is limited therefore factual validity is difficult to determine. However through the use of other resources similarities were distinguished regarding the descriptions provided for methodologies included.
Usefulness: This paper provides a clear overview of the Waterfall, Prototyping, Incremental, Spiral and Rapid Application Development (RAD) methodologies. Employing this writing style enables the reader to easily understand the information being conveyed.
Strengths: Succinct
Weaknesses: This paper provides an opinonated view of the methodologies outline. A number of the web references stated are no longer accessible doubting the validity and integrity of the information provided.
- Topic: The Soft Information Systems and Technologies Methodology (SISTem): A Contingency Approach to Integrated Decision Making and Development
Reference: Akinson, C.J. (2000). The Soft Information Systems and Technologies Methodology (SISTem): A Contingency Approach to Integrated Decision Making and Development. Requirement Engineering. 2(1) pp. 71-76.
Summary: This paper provides a detail account of the SISTeM, stating its evolutionary history underlining why this methodology can be considered a contingency approach to integrated decision making within IS development.
Critical Evaluation
Trustworthiness: Various references and case studies have been used to support the information provided within this paper increasing the integrity. The paper hasn’t been written in an ambiguous or bias fashion, an informative approach has been undertaken to explain the concepts involved.
Usefulness: A detailed account of the SISTeM has been provided identifying the concept of this particular SSM. Contingency approaches are alternative methods when conducting systems development. This approach enables a customized approach to be developed which applies to the organisation and development in question. This approach is useful as it enables flexibility within the development process, taking into account the system users, socio-technical and political aspects.
Strengths: An explanation has been provided outlining the tools and techniques involved in this methodology. A description stating the two cycles involved within this methodology was also provided. Cycle one identified that this focuses on high-level, strategic decision making. Cycle two focuses on operational decision making, which leads onto decisions of action followed by the processes of change. This methodology involves methods which facilitate a process of action based on problem solving and learning. A thorough account of this methodology is provided.
Weaknesses: Diagrammatical illustration included within this paper are somewhat difficult to understand and interpret. However textual information is provided to further explain the different aspects involved.
- Topic: Fujitsu’s Systems Development Methodology
Reference:
Oshima, T., Kashiwagi, M. & Fukao, H. (2006). Fujitsu’s Systems Development Methodology. FUJITSU, Sci. Tech. J. 42(3) PP. 277-285.
Summary: This paper provides a detailed account of this Method, Framework and development tools created by Fujitsu known as SDAS. SDAS is utilized within new technologies and has extended its scope to cover all life cycles of systems in Japan handling, analysis and development, maintenance and rebuilding of customer systems.
Critical Evaluation
Trustworthiness: This paper provides a factual account of the methodology discussed. The authors of this paper are members of the company hence this paper may have been written in bias fashion. Within this account there are no criticisms towards the methodology, all information is somewhat for the methodology signifying this as a success.
Usefulness: This paper indicates how companies create their own methodology to suit their environment. This has been identified as a successful approach according to the information provided. Many organisations state that the problem with methodologies is that they no longer apply to current businesses needs and the environment. Fujitsu providing this account identifies how they tackle this issue identifying an essential alternative approach.
Strengths: A thorough account of this methodology is provided outlining the structure, goals, Fujitsu’s approach to enterprise architecture, development standards, techniques and project management technologies.
Weaknesses: Now critical analysis of the methodology is provided outlining the positive aspects outlining no areas for improvement.
- Topic: The use of Systems Development Methodologies (SDM’s) in Telecommunication Industry
Reference:
Mazengera, B.M.A. & Huisman, H.M. (nd). The use of Systems Development Methodologies (SDM’s) in Telecommunication Industry. PP.1-2.
Summary: This paper identifies what is required of a Systems Development Methodology within the telecommunications sector. A clear emphasis is placed on a method which is continuously adapting to cope with the forever changing nature of the industry, providing an agile methodology. It’s important that a methodology employed manages and provides efficient methods for recognizing objects and developing these in a timeous manner.
Critical Evaluation
Trustworthiness: An unbiased, factual, comprehensible paper has been written identifying a number of references to support the information provided. A critical approach has been applied when analysing these methodologies, also the author has included a table identifying literature which links SDM’s and telecommunications strategies, which could be researched to gain further knowledge into this subject area.
Usefulness: Views on how methodologies are defined, what the predecessors of telecommunications methods were and their purpose are clearly identified. Three methodologies used within the telecommunications industry are stated MODA-TEL, Mansurov’s Accelerated Development Methodology and Mobile-D, identifying their characteristics. These were developed from formal methods as they are all Object-Oriented, Require extensive documentation throughout the lifecycle, Iterative development process, and timely during the initial stages of development. However the information provided is very brief, for a reader to gain in-depth information on these methodologies, further research would have to be conducted.
Strengths: A researched paper is provided identifying the requirements essential for the telecommunications industry. This conveys again that general methodologies are not equip to manage and control current developments as these are out dated and the environment in which they are operating requires a new tailored approach to be effective.
Weaknesses: A brief account of the actual methodologies themselves are provided.
Conclusion:
While conducting this assignment a range of factual resources were identified to obtain information regarding methodologies utilized when developing Information Systems. A variety of Methodologies, Frameworks, Approaches and CASE tools were researched including Structured Methodologies, O-O Methodologies and SSM. It became evident that information written before the 21st century was somewhat harder to acquire that information written previously. This was due to the fact that most of these Methodologies, Frameworks, Approaches and CASE tools were developed from and after the 1960’s, when their prevalence was recognized within the world of computing and Information Systems Development.
Since the 1960’s a number of methodologies have evolved further developing these Methodologies, Frameworks, Approaches and CASE tools to be more effective and efficient within today’s world. During the evolutionary period which is still preceding today a shift within paradigms brought forth the ideas regarding SSM, which began to take into account the socio-technical, political and User involvement when developing systems. This idea withdrew from structured approaches which were seen as inflexible and impractical to manage the developments within present dynamic organisations.
Within various literature often the author interchangeably used the termsMethodology, Approach and Framework. This provides a misconception that all three are in fact defined equally. This is simply not the case as distinctions have been conveyed. A methodology can be defined as a technique utilized to collate information employing a sequential method to store data. A framework can be defined as hypothetical outline influenced by a philosophical theory interpreted by the developer/developers, adapted to their scenario to implement a development. An approach can be defined as a Method, System or Framework used to implement a development.
Methodologies are still currently being used within organisations, however companies are developing more tailored approaches to suit their companies and users. This enables developers to respond quickly and efficiently within these dynamic environments. Methodologies present a controlled condition in which complex systems can be developed.