The Basic Unified Process

I have never worked on a large software team – in fact, most projects that I have been involved with, did not have more than two participants. Still, getting some insight into software development on a larger scale seems like a worthwhile exercise. Recently, I have been made aware of the “Unified Process” (UP) and started to read up on it. However, I quickly felt overwhelmed by all the talk about roles and disciplines and what not, and could not help but wonder: This seems like total overkill! How does this all apply to small teams – the kind I might actually end up working with eventually?

A quick Web search brought up several variations of the Unified Process, which does not appear to be all that unified after all. A few of these variants seem optimized for small teams. One especially promising example is described in the white paper “Basic Unified Process: A Process for Small and Agile Projects” by Ricardo Balduino, Rational Unified Process Content Developer at IBM. The Basic Unified Process (BUP) derives from IBM’s Rational Unified Process (RUP), but was streamlined to better suit teams of 3 to 6 developers, working on small projects, often not lasting longer than 3 to 6 months.

BUP is organized into methods and processes. Methods are focused on the following disciplines: requirements, architecture, development, test, project management, and change management. Compared to the RUP, some disciplines, like Business Modeling, were omitted, while some others were absorbed into neighboring disciplines. The BUP roles are analyst, architect, developer, tester, project manager, and a catch all “any role”. The number of tasks and artifacts are reduced as well to minimize ceremonial overhead.

While simpler than the RUP, all the disciplines, roles, tasks and artifacts in the BUP still make up a huge collection of methods, of which typically just a small subset will apply to any given project. The BUP therefore organizes semi-ordered sequences of methods into custom tailored processes. These processes are subdivided into iterations, groupings of methods, which may be applied in parallel at different stages of the project.

I am not sure, how well I understood the details of the Basic Unified Process, but from my first impression this way of structuring software projects appears very logical and instantly applicable. While maybe not as general and powerful as the more complex Unified Process variants, the BUP seems to be a useful entry-point into the world of Unified Process project management. One, which is instantly understandable and applicable by people without prior large-project experience, like me.

Posted in ITE 221 | Comments Off on The Basic Unified Process

ITE 221 Blog Posts

Labor Day is just around the corner, and even though we are technically still in the height of summer, the retail industry is busy reminding us of the shortening days and our obligation to start buying stuff for the colder seasons. This includes the appearance of Halloween items in every second supermarket aisle since about a week ago. I guess the official Halloween season has expanded to more than two months now? Anyhow, this reminds me, that I should brush off my zombie resurrection skills to get ready for October… What better way to do this, than by resurrecting a dead blog? A blog, which, after its birth half a year ago, barely managed to stay alive for more than a single day? Yes, I am talking about this one…

So here it is: my official second attempt to start blogging! Some of my upcoming posts might be rather boring though: I need to write weekly blog entries on computer technology as a homework exercise in a class that I am currently taking at the Northern Virginia Community College. Instead of starting a new blog for just this purpose, I decided to integrate my homework posts into this preexisting blog. Most of the posts should fit in rather well, but there might be a few odd balls. Should you be specifically interested in the posts of this series (meaning, that you are probably either my teacher or a class mate) you will be able to find them all in the ITE 221 category. Have fun! Or at least… don’t get too bored reading this stuff.

Posted in ITE 221, Random Thoughts | Comments Off on ITE 221 Blog Posts

Including iTunesArtwork in Ad Hoc distributions

When submitting an App to Apple’s App Store, one must include a full sized 512×512 pixel version of the App icon to be shown inside iTunes. For Ad Hoc distributions, there is no place to upload such an icon. Instead, testers will usually just get to see a nondescript default icon when they drag your IPA file into iTunes. That is, unless you include an iTunes artwork icon directly inside your application bundle.

Unfortunately, Apple’s documentation on how to include iTunes artwork with Ad Hoc distributed Apps, is a little thin. Searching the Web brings up plenty of tutorials, but many of them turn out to be useless for legit Ad Hoc distributions. The reason is, that many of these tutorials explain how to add an icon file to your application bundle after it is already built. For example, they may recommend, that you first unzip your built IPA file, then add a PNG named iTunesArtwork to its content, and finally zip it all up again. Well, this might have worked at some time past, not sure, although even then probably only for installs on jailbroken devices. Today, iTunes will reject any modified IPA file, since such a modification after code signing makes the App appear as if it has been tampered. So, unless you want to go through the pain of re-signing the modified IPA file, for legit Ad Hoc distributions this approach simply does not work.

What must be done instead, is to already include the iTunes artwork icon while building. Judging from the tone of other tutorials, this might have been a problem in older versions of XCode. With today’s XCode, all one needs to do, is to drag and drop the icon file into the project’s root directory and name it iTunesArtwork. If you try this, simply make sure, that the file represents an image of 512×512 pixels, which can be stored either in JPEG (not recommended) or PNG format. No property list needs to be edited, no target settings need to be changed. Just “Build and Archive”, export the result as an IPA file to your disk using the “Share…” button in the Organizer, and you are done.

There is only one caveat to watch out for: The filename must match iTunesArtwork exactly, without any file extension! When saving a JPEG or PNG file on the Mac, most graphics programs will automatically add a file extension, which may not always be displayed in folder views. So, if after building following these instructions, iTunes still only shows its default icon, the first thing you should check for is, whether you might have accidentally saved iTunesArtwork with a file extension.

Posted in iOS Development | 4 Comments

Hello world!

After several months of contemplating, I finally decided to give blogging a try. So here it is, my very first official post!

A few weeks ago, I set up a shared hosting account with A2 Hosting, and bought the domain name codeandbutter.com to go along with it. At first I considered this Web space primarily as a “digital playground” to try out some Web design ideas, learn how to write PHP, and do similar experimental stuff. Maybe the front page could eventually be used to host a traditional online résumé or something similar. That was, once I would find the time and energy to actually write something up for it. I also considered maybe adding a blog, just to give it a try, but this was not intended to become the main purpose of this site at first.

So I installed WordPress and started playing around with it… and to my surprise it turned out to be much more fun than expected! I quickly converted some programming notes, which I found laying around idle on my desktop, into experimental private blog posts, and started adding additional material to them. In no time I had written more than expected and said to myself: “Well, you have been thinking about publishing some of your thoughts for way too long already…” (I had previously made several unsuccessful attempts at starting traditional home pages, and once seriously experimented with starting a Wiki.) “This is the moment to finally just start doing it!”

I do not know, where this will eventually lead… if anywhere. Maybe, a month from now I will have lost interest, once my initially enthusiasm has worn off. (With most of my projects, this seems to happen rather quickly.) But maybe I will actually keep posting. Only time will tell. Expect most of the posts in this blog to be of a rather technical nature: I have not chosen a strict topic yet, but for now plan to focus on coding issues. But I do not rule out, that completely different topics may find their way into this blog as well.

Okay, enough of this boring introductory blurb! Time to work on my “first real” post instead, which will be a somewhat polished version of one of those aforementioned programming notes.

Posted in Random Thoughts | Comments Off on Hello world!