Opening Note:
This is exam week and the last couple of weeks were course work right after the last hand up. In addition to the schedule constraints I realize that the amount of work I intend to put into any deliverable and into the project in general is in actuality always reduced to a much smaller amount. Also I realize that I always feel slightly dissatisfied with the hand ups that i have made so far. Half the battle is knowing the problem - with that said my aim for the next deliverable is to try my best to produce work other that what is acceptable but that will add to my confidence and positive attitude toward this project. I love the work I do and this project means more to me than just a report and a piece of software at the end with hopes of a a passing grade. I know for a fact that this project is a part of me and the only way I can make it valuable is to place some of the value that is me in the efforts I make in it.
Even before my associate degree, I have been made aware of the bad reputation that IT (networking, data centers, repairs and especially programming) departments have when it comes to projects. It was so prominent that IT projects were commonly associated not only with being costly but in addition to having little or negative returns they were primarily known to be unfinished.
This was reinforced in a course i took called System Analysis and Design. In addition to IT departments earning a negative label, IT personnel and professionals were now generally thought of as "too technical" and unable to act in managerial roles.
This article makes some general evaluations that are backed by statistics. Some of which are astounding -
In addition the BSc Computing from UOG specifies that we evaluate the methodologies we are going to employ during the lifetime of the project.
Also I think it makes report writing and project management easier. The tried steps that have been refined by others give cognitive steps as to how to follow through the stages of the project. (So if i ever have doubts as to what i should be doing next the methodology should lead the way - along with my project lecturer).
Using a methodology will also allow me to deliver a more relevant analysis, development, deployment and testing in the critique of the work done. I will better be able to show what i was trying to accomplish to the markers and if i did indeed succeed and at what level by using the documentation specified in the methodology.
So we have established the importance of methodologies and why we need them for this project.
The following are some of the methodologies that are available for use in software development projects and over the next couple of weeks i hope to show how i gathered knowledge on them and use that in my justification of methodologies.
This is exam week and the last couple of weeks were course work right after the last hand up. In addition to the schedule constraints I realize that the amount of work I intend to put into any deliverable and into the project in general is in actuality always reduced to a much smaller amount. Also I realize that I always feel slightly dissatisfied with the hand ups that i have made so far. Half the battle is knowing the problem - with that said my aim for the next deliverable is to try my best to produce work other that what is acceptable but that will add to my confidence and positive attitude toward this project. I love the work I do and this project means more to me than just a report and a piece of software at the end with hopes of a a passing grade. I know for a fact that this project is a part of me and the only way I can make it valuable is to place some of the value that is me in the efforts I make in it.
Even before my associate degree, I have been made aware of the bad reputation that IT (networking, data centers, repairs and especially programming) departments have when it comes to projects. It was so prominent that IT projects were commonly associated not only with being costly but in addition to having little or negative returns they were primarily known to be unfinished.
This was reinforced in a course i took called System Analysis and Design. In addition to IT departments earning a negative label, IT personnel and professionals were now generally thought of as "too technical" and unable to act in managerial roles.
http://www.bcs.org/server.php?show=ConWebDoc.19584
This article makes some general evaluations that are backed by statistics. Some of which are astounding -
... the cost of project failure across the European Union was €142 billion in 2004.The article makes a bold statement about one of the reasons that IT projects fail;
I believe that even though at the root of projects, companies and systems, the driving force are the combined efforts and attitudes of the people involved, we can learn from the mistakes of the past by documentation and implementation of suitable methodologies and methods.
One of the major weaknesses uncovered during the analysis was the total reliance placed on project and development methodologies. One explanation for the reliance on methodology is the absence of leadership within the delivery process.
In addition the BSc Computing from UOG specifies that we evaluate the methodologies we are going to employ during the lifetime of the project.
Also I think it makes report writing and project management easier. The tried steps that have been refined by others give cognitive steps as to how to follow through the stages of the project. (So if i ever have doubts as to what i should be doing next the methodology should lead the way - along with my project lecturer).
Using a methodology will also allow me to deliver a more relevant analysis, development, deployment and testing in the critique of the work done. I will better be able to show what i was trying to accomplish to the markers and if i did indeed succeed and at what level by using the documentation specified in the methodology.
So we have established the importance of methodologies and why we need them for this project.
The following are some of the methodologies that are available for use in software development projects and over the next couple of weeks i hope to show how i gathered knowledge on them and use that in my justification of methodologies.
- eXtreme Programming
- Prototyping
- Rapid Application Development
- SCRUM
- RUP
- AUP
- SSM
- OOSD
- Waterfall
No comments:
Post a Comment