Agile Development......

Wikipedia on Agile Software Development 

Agile software development is basically a set of software development methods that promote adaptive planning, development and delivery.

What I thought was most interesting about agile software development methods is that they were developed to completely contrast waterfall methods because many people thought these methods were too "micromanaging".

 The Agile Manifesto, which basically started the movement of agile software development, is based on 12 principles:

1. Customer satisfaction by rapid delivery of useful software
2. Welcome changing requirements, even late in development
3. Working software is delivered frequently (weeks rather than months)
4. Working software is the principal measure of progress
5. Sustainable development, able to maintain a constant pace
6. Close, daily cooperation between business people and developers
7. Face-to-face conversation is the best form of communication (co-location)
8. Projects are built around motivated individuals, who should be trusted
9. Continuous attention to technical excellence and good design
10. Simplicity—the art of maximizing the amount of work not done—is essential
11. Self-organizing teams
12. Regular adaptation to changing circumstances

I prefer waterfall-oriented approaches to agile development because I see many issues with the above.

   1. "Customer satisfaction by rapid delivery of useful software" - this shouldn't even  be stated because I believe this to be a founding principle in all software development

   2.   "Welcome changing requirements, even late in development" - not very reasonable.  There has to be a "feature freeze" date so that the customer does not tell you that they want a feature that tosses people they don't like into a black hole 2 days before the program is supposed to ship.


   3. "Face-to-face conversation is the best form of communication (co-location)" - I agree with this and it's a lovely thought, but with growing technology and things like repositories for code, many people can work on a project or talk about requirements without ever meeting face-to-face.

I personally like the idea of trying to squeeze every last drop of information from the client at the first meeting to establish a set of requirements and use waterfall-oriented approaches.  The agile development approaches just seem too laid back and unproductive.

Reaction to Wikipedia on Use Case

Use Case

According to Wikipedia, a use case "is a list of steps,typically defining interactions between a role and a system, to achieve a goal." 

It seems to me that a use case is basically a step in the process of developing functional requirements that models how components of a program will interact with each other.  Many of these use case examples could be pictures such as UML or even memory and pointer diagrams.  

From Alistair Cockburn's "fully dressed" model, the Design Scopes and Goal Levels steps seem a big confusing and unnecessary.  I personally believe that if I was looking at a use case, I should be more concerned with the top level ideas of how a system interacts than trying to remember what a solid box and hollow box mean.  Knowing the design scope and the goal levels of a use case is useful information, but should be conveyed in words.  

One of the biggest benefits that I see to use cases is that they make it clearer exactly what role each part plays in a system and everyone working on a project with access to the use case can typically agree on the requirements.  This also depends on the quality of the use case writer though.  

All in all, even though use cases provide much more information, I would prefer a user story to a use case.  Some of the examples of use cases are a little convoluted and may be a little too much for the task at hand.  

Tentative Timeline For CS460

Timeline

Here is a link to the tentative timeline for David Daily CS460.

https://docs.google.com/viewer?a=v&pid=forums&srcid=MDY2MzAyNTU5MzAyNTAwOTQ3OTYBMDE2NDU1NDI1MTE1NzMwMjIxNjkBcGltZllKaTJURE1KATQBAXYy&authuser=0

Concept Paragraph For CS460 Project

Concept Paragraph

The Idea

In the world today, there are many applications and devices that tell you exactly where you are in the world and very accurately.  However, none of these are able to tell you your location without a satellite.

The Proposal

Our team will create a positioning system that can tell a user their exact latitude and longitude, or can tell them where an object of interest is that is equipped with one of these devices.  It will do this by calculating solid earth tides and readings from accelerometer stations around the world, and use the results to calculate longitudes and latitudes.

The Audience

The current audience for this device is anybody that needs to find their way around, but will be especially military and international cooperation organizations since it will work in places that GPS cannot.  For example, say the United States sells a super computer to China and China has promised that it will be kept at a university and used for educational purposes.  If the computer is equipped with one of these devices, the U.S. would be able to intermittently query the device to find its position and make sure the computer is always at the university.

Support 

For this product, my team will offer updates and new technology that will make it possible to query devices in real time with no satellites.  Also, there will be updates being released to the public to expand our market and make this technology a feasible solution for that "GPS signal lost" message that is so fun to hear on a road trip.


Call to Action

Not only could this device change the way that the military locates machines and people, but it could change the way that people find their way around.  After all,  I wouldn't trust a satellite that is 1,000-22,000 miles above the earth to tell me where the nearest McDonald's is, would you?

Software Engineering - That Wikipedia Thinks 

Some Interesting Things Wikipedia States That I May Not Agree With

 - "Software engineering is the practice of computer programming, while computer science is the theory of computer programming.".... meh not in my opinion

 - "some students in the developed world avoid education related to software engineering because of the fear of offshore outsourcing" - though this may be the case, there is a lot of software being written for government purposes and places where security clearances are required, so there will always be domestic need for software engineers

What Was Kinda Neat About The Article

 - The Waterfall model is very straight forward, yet has a good structure of the way good programs are created

 - I thought it was interesting, just for personal knowledge, that companies like Apple and Microsoft sponsor their own certification exams....which is probably a good thing

 - "Software Engineering sees programmers as practitioners of a well-defined engineering approach with the connotations of predictability, precision, mitigated risk and professionalism" - I think this is the coolest sentence because these are things programmers need to really focus on for their software to make an impact. If these things are forgotten about.......well.......you get iOS

Personally,

I feel as though software engineering embodies the more business and standards aspects of computer science such as:

 - Developing standards as to what is "good" programming and what is "bad, ugly, sinful" programming

 - Getting projects completed in time and sacrificing features to meet budget, but maintaining the functionality that was initially promised

 - Being able to interpret a customers wants and needs and give them back a program that is capable of what they need to do with it

and Computer Science

- Is making neat stuff and hacking for the fun of it

I wish the article

- Had talked more about the soft skills aspect of software engineering

- Talked about how it's a profession where the majority of time spend is modelling things that would be impractical to research in real life

-