64 Bytes

just a few characters short of a code base.

IPhone vs. Instinct Round 2 (the knock out).

clock July 20, 2008 12:18 by author Josh

In my previous post I spoke about the wonders of Sprints new Instinct. And don't get me wrong it is a great phone.. But the luster quickly wore off.. Why? Well like all non "Apple" product it didn't "just work".  Now I'm not going to bash Sprint or Samsung. They tried really hard, they gave it a valiant effort.  But in the end things just stopped working and Sprint was unable (in my case) to fix them.. The issues I had were as follows.

  • Exchange integration never worked
  • Contact Sync stopped working when my number was ported and they couldn't fix it (at least not by the time I cancelled the service.
  • Browser got worse the more I tried to like it.. (I really wanted to like it, but it just couldn't hold up to the iphone).
  • Tethering was techically possible but a Billing problem made it not work.. Tethering was almost worth keeping the phone, but Sprint CS said it was not likely to get fixed in the near future (something to do with the new Packaging).
  • Sound quality wasn't that great. It wasn't that bad; but its no good and the speakerphone was all but useless.
  • Customer service is lacking.. Sprint trys to be nice, but there customer service team is all but useless. They are very nice about being useless, but still useless non the less.
In the end I waited inline for a 3g iphone.. And let me tell you.. 3g + everything else an iPhone does + everything "just works" and, ya its just a winning combination.

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5


Instinct Vs. IPhone

clock June 22, 2008 14:15 by author Josh

So given that the 3G iPhone is just around the corner and Sprint has a 30 day cancellation policy on their accounts; I decided it would be fun to play "phone evaluator" for a few weeks while I waited for the 3g iPhone. So went down to the sprint store and got myself a Samsung Instinct. Now I have had an iPhone since June 30th 2007 and it is a great device.. Below is a breakdown of how the two devices compare. Now for the most part these two devices are very similar in functionality and design.. So I'll just breakdown who has what vs. the other; And how similar features compare. Also, assume 3g Iphone here or atleast iphone 2.0.

 iPhone:

  • Actual Exchange integration with ActiveSync for Email, Calander and Contacts.
  • View PDF and Word Docs
  • iTunes Music Store
  • iTunes App Store
  • MultiTouch Interface
  • 3G network

Instinct

  • MMS
  • Exchange support (email only)
  • Turn by Turn navigation
  • Live TV
  • Internat Radio
  • Sprint Music store
  • Location based Services with Voice Command
  • Location based movie search
  • Voice Command
  • Voice Dialing
  • EVDO network
  • Extra apps like News & Sports
  • Hyptic feedback (the phone kinda feels like you are pressing a button when you press something because it buzzes on press and when you let go)
  • Tethering (ok its not on the phone yet.. but technicly it supports it and Sprint is working on fixing the "Simply Everything" plan so they can fit in Tethering as an addon.)
  • Messaging is included in your plan.. SMS isn't an add on Yah!
  • MicroSD slot with support for HDSD (or atleast up to 8 gig)
  • Cheaper: $129 with 2 gig card.
  • Removable Batteries and the phone comes with 2 batteries AND an external charger (so charge in phone, and keep the spare charged too!)

Overlapping features and Whos is better.

  • Webbrowser: Now Sprint and Samsung gave it the old college try, but without multi-touch they just don't have the same elegent easy to use experience that iphone users (like myself) enjoy all the time.. But its not bad.. I would say a solid 2nd place for those I've used.. Oh ya, and the Samsung browser doesn't seem to support aJax.. Some javascript, yes.. but not Ajax for some reason.. 
  • Mail: Again the iPhone can leverage its webbrowser so its got html mail and it looks and works flawlessly
  • Virtual Keyboard: Again the iPhone wins.. Samsung trys but with the smaller screen they can't fit a qwerty keyboard in portrait mode. Instead you can have one in landscape or you can use an alphabetical keyboard OR a stylest input in portrait mode.
  • Touchscreen: Again (I'm sounding like a broken record) iPhones multi-touch screen is just more responsive.. I find my self pressing things 2 or three times on occation..
  • Volocity style Scrolling (zoom your finger and the list zooms): Guess what.. iPhone wins again.. The biggest problem with the  Instinct is that it keeps miss selecting stuff after I try to scroll... the iPhone is just smarter about this
  • Full size headphone jack with mic/answer button support: I was so happy to see this, but a SUPER simple feature was left out of the Instinct that makes the iPhone better. You can't use the mic button on the  headphones to skip songs or pause media play! Ya ya, its SOO simple but man that is one of my favorite iPhone features.. I have a set of headphones for my iPhone with just 1 earbud (cut the other one off) so I can cycle with it.. And having that button to change tracks is great.. Especially when I need a little more out of my music because I'm on a tough hill!
  • Development enviroments: I'm not going to choose a winner here. The iPhone has Apple impossed limitations and the $99/year app distro costs; and you can only code on a Mac.. Instinct is a Java based platform and it doesn't look to limit too much (haven't dug that deep), but you'll be lucky if you have 1/10 the audiance of an apple app.. 

So in the end who wins.. Well the funny thing is as much as the iPhone beats the Instinct on every overlapping feature. None of them (for me) are deal breakers.. Its all the extras (like the tightly integrated location services or voice dialing & voice commands) that make a winner out of the Instinct.. Ya you heard it here first, I like the Instinct MORE than I like my iPhone.. Now I have about 20 days to continue testing and decided if in fact my initial opinions hold thru till the release of the 3g iPhone.... But at the moment, I think Sprint has a winner (all be it probably under appriciated) in the Instinct.

 

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5


The 3 W's and H of software development.

clock June 5, 2008 14:17 by author Josh
So a non software developer friend of mine posed the open-ended question "How" to me in an email.. below is my response..  On reflection, it is a wonderfully simple description of a healthy SDLC... Overly simple, but perhaps something you can describe to a client and make the whole process more consumable and understandable :-)
Lets start with a life cycle that leads to the completion of the action that "how" proposes.. After all, how is just a question that defines an action (be it completed or proposed)..

1) Who: One must define the actors, after all "How" is either enacted on or by something/someone.

2) Why: Why is like a compass, it points the way and helps shape the goals of what How will achieve.

3) What: What is the MOST important question.. It is the goal that How will make real.. If you don't know what, then how is just the definision of random action..

4) How: wondered when we would get here hu :-P... As a developer I like to think of How as the answer to What..

5) Do Stuff: now that you have how you start making it happen.
(Rinse and repeat whole process until final goal is achived).

Really each question is the answer to the previous question such that you eventually have a defined action to take.
 (The title is in deference to my 4th grade teacher who always tought me that good journalisum was the 4 W's and H (Who, What, Where, Why & How).. )

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5


I still ♥ Ruby on Rails...

clock May 20, 2008 07:23 by author Josh

Over the summer I finally dug into this whole "MVC" thing for web development. Naturally I began with the Mecca of them all Ruby on Rails.  This was a twofold learning experience for me..  First off it was Ruby a meta-language that bends like read in the wind.  And second was Rails, the darling framework that seems to have been sent by the demi-gods of software to help all suffering web developers.

But all of this joy was not without its flaws. Ruby is (as I mentioned before) all but un-deployable on a windows platform. After all Ruby is a single threaded/multi-process language (great for Unix where you don't actually have threads). But this limitation makes it an un-workable option on a windows box. Since then I have dug into Monorail, and now am neck deep in ASP.NET MVC. Heck I'm even a committer on the MVCContrib project. And while these projects are great they are still missing some magic. 

In short I still have stars in my eyes when I think of RoR.. This brings up the question, Why? (ya simple question).  I've been thinking about this a bit and I think (for me) the issue boils down to just a few issues.

First off is the RoR mantra "Convention over Configuration".  This mantra is actually quite deep; and while it can be a touch annoying at times (class naming can get silly) it's actually insanely smart. I have probably downloaded 15 different rails projects and had a working knowledge of the app and how to tweak each one in less than an hour. This is because the sites structure is described 1 way and 1 way only. More over I have been able to hand over projects in no time flat. In short, getting up to speed on a rails project is a no brainer.  ASP.NET MVC missed the mark on this in a big way in my book. MS, wisely from an OO perspective, laid everything out in a strong override-able and design. If you don't like routing, just implement a new router, don't like the view engine, just replace it. MVCContrib continued this with implantations of DI containers like Winsor, Structure Map, etc.. To muddy the situation further, MVCContrib implements multiple View Engines allowing developers to choose between ASPX, NHTML, NVolocity etc.. With all of that we diverge from Convention, and in doing so remove elegance for the privilege of flexibility (* Flexibility I am sure I will be thankful for when I migrate some of my Monorail apps to ASP.NET MVC over the summer).  Monorail is also bad about this (although not as much) with multiple view engines and a solid OO framework; but monorail has a community that has become kind of set in their ways. And so, while not set in stone, some conventions have settled in.  But going back to the rails mantra "Convention over Configuration"; nether ASP.NET MVC or Monorail prescribe to this philosophy more over they are the opposite "Here's a convention, but here are 108 tools to ignore it with " (I jest). 

    The second great feature of rails is the data model versioning and deployment methodology. You want a new data model, you add a new class to your data model describing the changes. Deploy the new version to your dev db, then code. Once your are done you run your deployment in test, evaluate your unit tests and push to prod; all very elegantly and with little effort. Linq for SQL has a great model but you design the app to the data (pulling your object structure from your tables) not the other way around.. So the same model change in Linq starts at the DB (with change scripts so you can manually run them in test and prod later) then re build your mode, code, test, run scripts in test, run unit tests, and deploy using your ant script that took 2 days to write. That's a lot of work and unfortunately Castle active record isn't much better.

    No don't get me wrong I really enjoy using Monorail and ASP.NET MVC has real promise. But when you take these three MVC frameworks and you look at developer efficiency and experience RoR is closest to my heart!

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5


Week 5 Question 1 - Requirements Gathering (Round 2)

clock February 10, 2008 04:24 by author Josh

Question:

 The director of IT would like to know more about enthography, and suggestions on weather or not it should be used in the organization.

Response: 

    For starters, weather you know this term or not ethnography is a staple is business process analysis and review. Ethnography, put simply, is requirements gathering thru observation. Weather we call it ethnography, a work session, a focus group or any other number of observation techniques the key to remember is it’s an excellent tool for seeing how well a current process is working.

    One of the best BA’s I ever knew could sit down and observe two or three users of a business unit, ask a few key questions and peg the main roadblocks in that groups daily work (she was quite talented). Ethnography, based on some of the material I reviewed, has a multitude of methodologies. It can vary from a very formal, almost “academic”, approach of video tapes and avoiding contact as much as possible, to an extremely light and informal working session where questions are just kept to a minimum. Really it all depends on your goal and target audience as to how far you want to go. Perhaps if you are running a study or focus group the more formal processes may provide better insight into something like a consumer level product. Contrasting that extreme, a small team working with a business unit inside an organization may want to drop by a subject’s office and have a quick working session and take some casual notes. The key to remember is it’s all about what you want out of the process.

    As a recommendation, well ethnography is already in use. The process is a key asset in the toolbox of requirements gathering. Perhaps the name isn’t attached but, yes the method is already in use. That’s not to say the process couldn’t be optimized, and as such it is probably wise to review our techniques as they compare to the more structured implementations of requirements gathering thru observation.

Refrences:

  • ilikecake(2008), Ethnography retrieved on February 7th 2008 from ilikecake website: http://www.ilikecake.net/hci/requirements/ethnography.htm

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5


Week 4 Question 1 - Requirements Gathering.

clock February 3, 2008 08:32 by author Josh

Question:

Propose what a team that will handle requirements gathering might look like, what tasks they must do and what resulting assets may come out of this phase of development.

Response:

Requirements gathering, possibly the most crucial step in software development, is often times the first “real” step a company takes in developing an application. That’s not to say that Scope Definition and problem analysis don’t happen. Its just that Requirements Gathering is often time considered the “kickoff” point from the perspective of most business users.  The goal of requirements gathering is to create a definitive description of exactly what the solution must do in order to resolve the business problem and be considered a success.   It is during this phase that we work most closely with the system users to derive these requirements. 

 

One reality about Requirements gathering that many don’t realize is that it is more likely that your business users and system owners don’t know their own business processes than it is that they do.   As surprising as that sounds it really isn’t bazaar,  many users are far too busy to analyze what they do plus get a strong understanding of how they fit into the organization as a hole.  And while system owners may have a strong high level understanding of what their business does, the minutia of the process that achieves that is often abstracted from them.

 

If this sounds like an uphill battle, that’s because it is. But if you assemble the right team,  excute the right tasks (often times over and over and over again), and diligently develop and manage the right artifacts;  then you can come out of requirements gathering with a solid foundation. Often times this leads to the requirements gathering team to have a better understanding of what the business does, then even the business users or the system owners do. 

 

The Team:

Project Manager:  The project manager acts mostly as a facilitator during requirements gathering, they will be working to get the right people together in the right room so that requirements can be acquired thru interviews, observation or other techniques.

 Business Analyst:  It is the responsibility of the Business Analyst to capture the requirements. They will work with the users to understand what they do, what they need, and how to put the system together to get them where they need to go.  Business Analysis is part art and part science and requires exceptional people skills as you help lift the fog surrounding what the system needs to do.

System Users:  System Users are the Business Analysts primary contact. The Business Analysts will meet with System Users as many times as it takes to get a solid and complete understanding of what is needed.

System Owners:  Often times there will be gaps in understanding between the various System Users; the System Owners are the best place to start to either fill these gaps or find out who will be filling these gaps. They are also an excellent “sanity” check. Its surprising how often one can hear “they do/want what?”  from a System Owner when a BA is explaining the process they have obtained thru their interaction with the  System Users.

 

The Tasks:

The tasks involved are really a cycle of specific tasks. Thinking of it like a mini process helps, below are the tasks involved in requirement gathering.

  • Requirements Identification – Learning of a requirement and defining it in as much detail as possible.
  • Prioritizing – Define how important the requirement as it relates to other requirements in the system
  • Project Impact – New requirement means a new project plan. Fit in the new requirement and evaluate its impact on the entire project.

·         Update documentation – Once we have a full understanding of the new requirement we have to serialize it into documentation. To do that we must update our requirements documents and models. These documents are how projects are defined and the center of communication. It is crucial that these documents stay as up to date as possible.

The Artifacts:

The artifacts are those documents that are the center of communication between the different members of the project team. The key is to make these documents as throe as possible, while making sure that all members of the team understand them.  There are many different types of artifacts that can be used, and it is best to view different types of artifacts like tools rather than items that must exists. After all the goal of these artifacts is for communication, if an artifact isn’t successful with your team, don’t waste cycles using it.

Example Artifacts:

  • Requirements document – A hallmark of this state. Often times these documents are hundreds of pages long and provide very detailed descriptions of each function of a solution. Sometimes this document is called the Functional Requirements document.
  • Business Process model – A series of workflows and state or status diagrams and descriptions that act as a high level overview of how the different requirements interact
  • Business Data Model – This document describes the data that the solution must capture and work with. It is often times that this document acts like a dictionary. Its description of different objects helps users understand what the other documents and models are describing.
  • Screen shots or UI Model – These documents work to help describe how screens will function. Often times they include descriptions of every field that will be viewed or edited on a screen along with mapping information to specific points in other documents like Requirements or models.
  • Stories – Stories are used in Agile development and are like mini versions of all the above documents. The specifies of a story are much more laxed leaning more on the idea of the bear minimum to make a requirement understandable rather than a ridged and in-depth description.
  • Acceptance Testing document – Sometimes it is easier to describe a piece of functionality by describing the test that validates it. In these cases, writing a few tests cases early is worthwhile. After all, any project worth its weight in salt will have one of these anyways.
  • Use Case Models – These are often very high level graphical representations of requirements, defining all of the actors of the process and what the process will do.

 

 

 

References:

Whitten, Jeffery L., & Bentley, Lonnie D. (2008). Introduction to System Analysis and Design. New York: McGraw-Hill Irwin.

 

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5


Week 3 Question 1 - Handling Scope Creep

clock January 24, 2008 16:05 by author Josh

Question:

 You are working on a project, and during the prototype review the client has come up with some new requirements. The project is constrained by both its budget and its schedule. How do you handle this change in scope? 

*Note to protect the innocent I have paraphrased the question.

Response:

It is very common when developing an application that the user base will have changes. The fact of the matter is, rarely does a client actually know, in complete detail, what they need.  That kind of forethought is just not the kind of thing you can expect from your clients. There are a few approaches to handle these changes and it really depends on the client and the methodology you are using to develop the project. To keep things simple I’ll describe methods to handle this kind of issue in both an Iterative (Agile-esk) and Watershed (RUP-esk) methodologies.

Iterative:  This is the bread and butter of an Iterative process. When dealing with change in an iterative process your first goal is to capture the new request. The Requirement or Story is recorded and added to the development queue. The client then prioritizes the new feature and places it in one of the pre scheduled iterations. If other requirements are not reached before the schedule or budget ends then so be it.  One of my peers is on a SCRUM project at a major PC Manufacturer, and the management actually funds each SCRUM sprint (iteration) at a time.  If the business users see a need for the next sprint then they fund it. If not, the project ends.

Watershed:  While the process will sound similar to Iterative; the decision making and the process that follows is much more structured.  First an analysis of the new request is done, requirements are defined, and impact is scoped.  Once the request is fully understood you have a few chooses. Option one is you can push the new request out until a new phase. Or you can feed in the request into your change management process. This may include your client making some tough decisions about what features they are going to push out or cancel to make room for the new feature.

The fact of the matter is, if a project is truly constrained (with no wiggle room) then you can think of your project constraints like a budget and requirements like bills you need to pay.  When you run out of your budget you can’t pay anymore bills, it’s as simple as that.

Now for a touch of reality, when I am engaged with a client I always make sure they understand that no one truly captures all of their needs in the first pass. As such they should always plan for either financing a second phase OR adding a decent amount of wiggle room to cover these kinds of events. This is really common during the deployment and stabilization phase (when users actually start using the app) and I just refer to this as the “shakeout” period. In fact the bigger the project, the longer the shakeout.. During the ERP app our shakeout was almost a quarter long as different departments went thru actual monthly and quarterly closes..

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5


Week 2 Question 2 - System Modeling

clock January 18, 2008 03:13 by author Josh

Question:

 Someone has asked you to define the models nessesary for the System Analysis phase of the process. What Models would you suggest and where would they be created in the methodology we are using.

*Note to protect the innocent I have paraphrased the question.

Response:

For system analysis to succeed we must enter this phase of development with a strong understanding of what the business goals are and edit the phase with a complete understanding on how we are going to achieve that goal in a technology agnostic  taxonomy.  

A few choose quotes from a former mentor of mine are especially apt here so I am going to paraphrase them before I continue answering this question

  • Software development is like asking a question and answering it.
  • A complete set of requirements is the question. Without a complete question , you don’t know what you are answering
  • Requirements should be unambiguous, understandable and testable. If you can’t test it how do you know you have met the requirement?

-Mentor (not going to use their name on a public site :-P)

System Analysis using our development methodology consists of Requirements analysis and Logical Design. By the time you exit Logical Design deliverables will include Business Data Requirements, Logical Data Model, Business Process Requirements, Logical Process Model, Business & System Interface Requirements and finally Logical Interface Model.  But not all of these are models and some may include “mini” models as to support the text in the documents. Below is how I would break down the models across these two phases with more specificity.

Requirements Analysis:  This phase will produce mostly documentation and not models, the documentation from this phase will be consumed to produce formal models. However some modeling will help support this documentation and make it easier to be understood.

-          Use Case Models: Use Case models are representations at a fairly high level of a requirement. They employ graphics to represent Actors, actions, inputs and outputs.

-          Sequence Diagrams: These diagrams can help describe how a process executes. The graphic representation of multiple separate processes and how they communicate and react to each other is the goal of this kind of graphic

-          State Diagrams: These can describe the various states of a business entity, interface or process and how that state may change its properties.

Logical Design:  The goal of Logical Design is take Business requirements and map them to a system. Maintaining a technology neutral stance these models may have the look and “feel” of what the system will do, they avoid implementation details or making decisions that could limit chooses during Decision Analysis. These models may also leverage more detailed versions of the above mentioned Use Case, Sequence and State models.

-          Logical Data Model:  This model describes all of the data needs of the application in maps that include field requirements and relationships. Logical Data Models are a lot like a dictionary of what specific business entity is.

-          Logical Process Model:  This model will be a series of flow charts, use cases models, sequence diagrams and other supporting material that turns business requirements into defined processes.  The end result of a Logical Process Model is to define each specific process and describe how that process will flow, and how decisions in that process will change the outcome.

-          Logical Interface Model:  The interface model will help define how inputs and outputs will be parsed across the application. This will describe where data should be rendered and where it should be required. This may be described in State Diagrams, Screen mockups, and Logical Data Model based interface requirements with external systems.

 

So while I would have to make my describe these quickly, those 3 Logical Models and three types of supporting models are what I would  present as required for the System Analysis of the application.

References

Whitten, Jeffery L., & Bentley, Lonnie D. (2008). Introduction to System Analysis and Design.New York: McGraw-Hill Irwin.

Fowler, Martin & Scott, Kendall (1999).UML Distilled Second Edition, A Brief Guide to the Standard Object Modeling Language. New Jersey: Addison-Wesley.

 

Currently rated 4.0 by 1 people

  • Currently 4/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5


Week 2 Question 1 - Capability Maturity Model Level

clock January 18, 2008 03:07 by author Josh

Question:

What steps would you take to evaluate a companies CMM level and what evidence would you look for to validate that they met a given level?

*Note to protect the innocent I have paraphrased the question.

Response:

To analyze the current CMM level of an organization I would conduct a series of tests, interviews and sample for evidence. Based on the results of those I would be able to evaluate an organization’s CMM level with some level of accuracy.

Interviews: the goals of these interviews would be to evaluate both internal and external perceptions on what methodologies and tracking processes are in place for the organization.

-          An Executive that is not related to IT

-          A Business user not related to IT

-          Executive in charge of IT (could be a CIO or Director of IT)

-          Manager of Network Operations

-          Software Development Manager

-          Software Development Project Manager

-          Software Development Techical Lead

-          Software Developer

-          IT Support Desk Rep

Tests: The function of these tests will be to evaluate how competent the users are of their process. These tests may include further interviews asking specific questions about the organizations processes and comparing those to the documentation obtained. These test may also extend into watching users of the process actually enact tasks in the process.

Evidence: It’s one thing to talk the talk. But only with evidence can you prove that the organization is in fact using the process. Evidence will be asked for with little to no warning and will need to be pulled from the system with the evaluator present. The sample set for evidence to be pulled from will include all projects for the last 18 months plus at least 6 completed projects. We will be sampling for evidence that the software process is executed consistently and documented as such.  Evidence may include documents, emails, helpdesk tickets, reports derived from any in use Methodware, meeting notes and Groupware archives of scheduled meetings.

Evaluation: Once all of the data is received we would evaluate the results comparing interview notes, tests & evidence against the organizations published process. We would also compare the organizations published and actual process against industry best practices below is what we are looking for to reach a specific CMM level.

1)      Initial :

a.       The organization has completed at least one project and it has been deployed to production.

b.      The project includes at least basic documentation to validate that the application was requested and meet the business users needs

2)      Repeatable:

a.       The organization has demonstrated at least 60% of their projects use the same basic methodology.

b.      The organization has demonstrated that both the internal and external users are aware of the organizations endeded software development methodology and its general process as it affects them

c.       The organization has completed at least 3 projects that follow the accepted methodology with minimal deviation without documented explanations for deviation.

3)      Defined :

a.       Specific process documentation and or Methodware was delivered to the Review team at the beginning of the evaluation.

b.      The organization has demonstrated that all project have used the methodology since its approval date or documentation is provided with excepted explanations as to which projects deviated and why.

c.       At least 50% of all projects demonstrated execution of the documented process.

d.      All users of the process know where documentation is stored in the organizations systems and have a strong knowledge of its methods without referring to the documentation.

e.      The documented process has been in effect for at one quarter (3 months)

4)      Managed:

a.       The documented process has been in effect for at least 4 quarters (one year)

b.      Process evidence is primarly provided by a single system rather than a mixture of emails, meeting notes and other ancillary evidence.

c.       The organization has reports that demonstrate quantifiable details regarding a projects success or failure. This should include estimates vs. actual for man hours, cost, schedule, administrative overhead, defect tracking, customer feedback.

d.      All current projects are presented in the organizations tracking systems and are accurate to within a reporting period.

e.      At least 5 now complete projects used the tracking system from kickoff to completion of the project

f.        All users of the tracking system have logins to the system.

5)      Optimized:

a.       The documented process has been in effect for the entire sampling period

b.      Process evidence is provided solely from the organizations tracking system.

c.       Evidence is provided that the organizations process has been evaluated in accordance with IT policies.

d.      All users of the tracking system demonstrate consistent and repeated use of the system.

e.      The tracking system has enough data to provide baseline reports for comparison.

f.        The process includes a lessons learned and these are archived in the tracking system for every closed project

g.       Evidence is proved that lessons learned from all closed projects have feed into validate-able changes to the organizations processes (if applicable).

h.      Tracking System metrics & reports are ties to individual and organizational reviews not just process reviews.

Comparing the tests results to the above level qualifications would allow us to know which phase an organization is currently in and how close they are to the next phase of CMM.

So ya, I’ve been thru a few SOX audits (4 to be exact) so I am leaning a lot on how they test our IT department to make sure that we were meeting Sarbanes-Oxley controls as they relate to IT (and there are a surprising number of them that do!).

Whitten, Jeffery L., & Bentley, Lonnie D. (2008). Introduction to System Analysis and Design.New York: McGraw-Hill Irwin.

 

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5


Week 1 question 1 - System Development Roles

clock January 18, 2008 02:48 by author Josh

Question :  

There are multiple roles of responsibility for software development. Using your own research what roles are responsible for each phase of development in a project

*Note to protect the innocent I have paraphrased the question.   

Response:

Most people when they look to build a software development team will put together the “normal” group. This will generally consist of project owners, a project manager, an architect or technical lead, and a few developers. Reading over a few other posts it looks like some of the more formal development methodologies (like RUP) have been covered. As such, I am going to go a different direction with my post and cover the roles and responsibilities of the new darling of the methodology world; Agile.

The Agile Development methodology several other flavors as well, but, be it Agile, Scrum or XP they all have the same goal. The goal is to simplify development and bring the project owner in early and often! Now I won’t go much more in to those details here but just the loose structure of an Agile team will give you an taste for its less rigid style.

Agile really consist of between three to five roles. Below are five common roles; however there is overlap on some of them because some get rolled up into a single role or shared by multiple team members, in some cases.

  • Customer: These are the project owners (or their duly anointed representative). While I was at SigmaTel we called them clients, others may call them customers or sponsors. In short these are the people who want to what the project will deliver. They will be instrumental in requirement definitions (sometimes called stories), acceptance testing, and prioritization. These members are also tasked with managing the budget and the business case.
  • Developer/Implementer: These are the builders. Developers take a given requirement and turn it into functionality. This can include Architects, technical leads, coders or Database developers, Testers. Even members of the IT Ops team can be an Implementer if they are assisting in the completion of a project requirement. This is probably the most ambigous of all the roles, but that’s because Agile believes in removing titles and barriers inside a development team.
  • Facilitator: The easiest way of thinking of a Facilitator as anyone who is not described above. Project or resource managers are likely candidates for this role
  • Tracker (a type of Facilitator): The tracker manages time. Trackers are responsible for keeping track of deliverables, task completions, time estimates and well everything schedule related.
  • Coach (a type of Facilitator): Finally the coach. A coach is someone that helps the team keep to methodology. Coachs could be developers, customers, trackers, any role. What they are around to do is too help the team stay true to the process. This role is especially important when a team is first implementing Agile and its methodology is new to the team.

As you can see from the above roles Agile development is kind of the antithesis of structured development methodologies like Rational and while it may look “to loose” to work from here, but I’ll make sure to shed more light on it as the class progresses. (and subject matter dictates :-P).

Refrences:
Where Did All the Positions Go?
Agile teams means examining expectations and adapting skill sets
http://www.ddj.com/architect/187203749?pgno=1

Espresso Fueled Agile Development
http://blogs.msdn.com/mpuleio/archive/2006/05/24/606561.aspx

The Roots of Scrum:
How Japanese Manufacturing Changed Global Software Development Practices
http://jeffsutherland.com/scrum/RootsofScrumJAOO28Sep2005.pdf

Extreme Programming : Team-Based Development (Page 59-64)
http://www.oreilly.com/catalog/extprogpg/chapter/ch05.pdf

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5



Calendar

<<  August 2008  >>
MoTuWeThFrSaSu
28293031123
45678910
11121314151617
18192021222324
25262728293031
1234567

View posts in large calendar

Add to Technorati Favorites

Sign in