Although story has a software engineering context, the situation described there seems common for almost all kind of workplaces.
btw. I like the style of www.dadhacker.com posts.
2010-06-15
2010-05-31
Requirements management story
The development of simple specific project management system was set in motion. There were couple of meetings and email "conversations" about requirements and use cases scenarios. There was one administration like system role valid for period of time when system "project" was running. I asked client few times about replacing user of that role in case of illness days off etc.
It is not important now .....
The answers were: it is not important part of story, we can wait for finishing project business if there is enough time or substitute someone in place using the same system user, and finally there is only one administrative user for single "system project". The message was clear: it is not important, keep going, we can handle situation. The application was simple so it was looking like cutting the corners on unused features.
... but I cannot accept that ...
The story was finished till final acceptance tests. One of the users from client side playing such system "administrative role", get few days off. The other administrative user asks now for guidance because "there was something in manual about replacing users of other role in system projects". After reviewing quick "user doable" solutions he had serious objectives about completeness of the system. So either detailed "walk through" procedure will be enough or new feature have to be added to application functionality as a part of service agreement.
The role of Final user adoption
It's story about little detail but it shows common scenario that very often takes place during software development.
During requirements gathering the project team was planning common usage and sanely limited set of functionalities.
Every user thinks in a different way. Some will understand used functionality set, other will need detailed procedures for every specific situation.
Final user adoption is important thing. That is one of the reasons why so many classic waterfall project models fail. There are also stories about complete systems, agreed on paper but unused or misused by users that just didn't like it.
It is not important now .....
The answers were: it is not important part of story, we can wait for finishing project business if there is enough time or substitute someone in place using the same system user, and finally there is only one administrative user for single "system project". The message was clear: it is not important, keep going, we can handle situation. The application was simple so it was looking like cutting the corners on unused features.
... but I cannot accept that ...
The story was finished till final acceptance tests. One of the users from client side playing such system "administrative role", get few days off. The other administrative user asks now for guidance because "there was something in manual about replacing users of other role in system projects". After reviewing quick "user doable" solutions he had serious objectives about completeness of the system. So either detailed "walk through" procedure will be enough or new feature have to be added to application functionality as a part of service agreement.
The role of Final user adoption
It's story about little detail but it shows common scenario that very often takes place during software development.
During requirements gathering the project team was planning common usage and sanely limited set of functionalities.
Every user thinks in a different way. Some will understand used functionality set, other will need detailed procedures for every specific situation.
Final user adoption is important thing. That is one of the reasons why so many classic waterfall project models fail. There are also stories about complete systems, agreed on paper but unused or misused by users that just didn't like it.
2010-05-26
Spring cleaning time - making room for new activities
The Spring is very worky time for me. I'm not talking about casual house cleaning (I used to do it fast), but mainly about my work context. It's time to finish started projects and make room for new ones and for incoming summer activities. Weather in May is really nice in my place - so I devote some time to biking and long walks. I really didn't want to start another tasks, like writing blog posts about something abstract enough (I still have "blog vs privacy" issues). So please forgive me for long break without posts.
I'm thinking also about blog character- it's now mixed personal/technical blog. I like reading entertaining personal blogs, but that is not a point. It seems people like more specialized thematic blogs, so maybe I should go that way. I don't want to fight for readership with every possible mean, but more viewers means more potential interesting contacts for me.
Yes, I'm talking about you dear reader. So if you are interested in my subjects, or have an project/business idea write me itprolife@gmail.com.
I'm inviting commenters too.
I'm thinking also about blog character- it's now mixed personal/technical blog. I like reading entertaining personal blogs, but that is not a point. It seems people like more specialized thematic blogs, so maybe I should go that way. I don't want to fight for readership with every possible mean, but more viewers means more potential interesting contacts for me.
Yes, I'm talking about you dear reader. So if you are interested in my subjects, or have an project/business idea write me itprolife@gmail.com.
I'm inviting commenters too.
by
Tomasz Worona
2010-03-31
Good practices for backups on DVD
DVDs are good and cheap media for middle term backups of old files, or periodical snapshots that fit into 4.37 GiB space. Best example of mine is storing old photos.
Choose you disc
Choose good quality discs from known brand/manufacturer relying on reliability statistics
Choose DVD+R over DVD-R - +R uses better writing method and has better error correction, check this article for long explanation. Do not use rewritable discs that use erasable data layer, that could be more easily damaged.
Burning speed - the lower the best - higher speed means potentially more errors to correct during writing and reading. Most hardcore safe backup setting will be x1 , but 4x or 8x should be quite safe when today DVD writers give you x16 writing speed.
Handling
DVDs are fragile to physical damages, specially vulnerable to scratches. So discs should be handled with care, without touching recorded surface. Discs surface should be clean to avoid scratching by hard dust particles. Blank discs should be perfect clean before writing, as any speck on surface will block laser beam.
Do not place adhesive labels and use special CD/DVD markers for labeling. The best place for tiny label is not recordable small middle ring. Why is that? Label side of CD or DVD is separated only by thin layer, that chemicals could easy get through and damage data layer with recorded pits.
Recorder DVDs should be stored in dark and dry place. Here is nice list of DVD handling recommendations on a NIST page.
Additional backup safety measures
Redundancy increases probability of data retrieval. For critical data it makes sense to make more copies. Other copy could be placed off-site, for better protection in fire and flood proof place.
Another option would be additional error correction data created by ECC software like dvdisaster. The best option is to write additional ECC data scattered on the same disc with data. It's a trade-off of disc capacity for additional data safety.
Every media has limited life span even stored in best conditions. Some manufacturers give even 30 years (or even 100 years!) for DVD discs, but I'm not such optimistic. Stored archives should be periodically checked for errors (dvdisaster has that functionality), and then moved to new media. It makes also sense in case of technology change and migration. Today next popular optical format is Blu-Ray Disc, but its still young.
Choose you disc
Choose good quality discs from known brand/manufacturer relying on reliability statistics
Choose DVD+R over DVD-R - +R uses better writing method and has better error correction, check this article for long explanation. Do not use rewritable discs that use erasable data layer, that could be more easily damaged.
Burning speed - the lower the best - higher speed means potentially more errors to correct during writing and reading. Most hardcore safe backup setting will be x1 , but 4x or 8x should be quite safe when today DVD writers give you x16 writing speed.
Handling
DVDs are fragile to physical damages, specially vulnerable to scratches. So discs should be handled with care, without touching recorded surface. Discs surface should be clean to avoid scratching by hard dust particles. Blank discs should be perfect clean before writing, as any speck on surface will block laser beam.
Do not place adhesive labels and use special CD/DVD markers for labeling. The best place for tiny label is not recordable small middle ring. Why is that? Label side of CD or DVD is separated only by thin layer, that chemicals could easy get through and damage data layer with recorded pits.
Recorder DVDs should be stored in dark and dry place. Here is nice list of DVD handling recommendations on a NIST page.
Additional backup safety measures
Redundancy increases probability of data retrieval. For critical data it makes sense to make more copies. Other copy could be placed off-site, for better protection in fire and flood proof place.
Another option would be additional error correction data created by ECC software like dvdisaster. The best option is to write additional ECC data scattered on the same disc with data. It's a trade-off of disc capacity for additional data safety.
Every media has limited life span even stored in best conditions. Some manufacturers give even 30 years (or even 100 years!) for DVD discs, but I'm not such optimistic. Stored archives should be periodically checked for errors (dvdisaster has that functionality), and then moved to new media. It makes also sense in case of technology change and migration. Today next popular optical format is Blu-Ray Disc, but its still young.
by
Tomasz Worona
2010-03-25
Software development project size and methodology
Here is a short description of software development characteristics for projects of different size and its impact for methodology.
Very simple application (single programmer, tester - one man for all)
Requirements are simple and all known. If you are writing very simple application, using good architecture plan and code writing practices, as a result you should have clean ready to change application. Adding automated tests makes changes easier without software quality drop. You know all details without looking into documentation, and testing new changes and features during implementation. All changes go to the code repository with comments and TODO file.
Simple/medium, application (team of 1+ programmers and other stakeholders)
The requirements should be gathered and agreed before development. You are using some kind of Issue Management System, tracing all change requests. Application is divided into main modules referred in task details. Programmers know what to change and what are dependencies between modules and side effects of implemented changes. Testers know main modules, and are going through test procedures of modules and functionalities. Procedures are short and clean and there is a natural place for agile methodologies.
Large application, (team of 10+ programmers and stakeholders)
Application is quite huge. Preparing requirements is often separate project. Every change request is thoroughly reviewed then approved. Application have many interdependencies caused by re-usability and connection points. Some changes have strictly local effects for given feature, those are less harmful. Other change some lower level service, probably unit tested, but still having impact on bigger process. Automated tests are not covering every possible use of code, manual top level functional tests are last line of defense in quality assurance. In real life every module has many connections with other modules. Testers have very limited knowledge about those dependencies. Everyone needs more plans, documents, procedures and artifacts that is slowing down the whole process. Practical solution is to divide the large project into smaller, less complex sub-projects.
At this level of complexity there are many "process complete" management methodologies. The winning one is the best suitable for given project, reducing risks and allowing to finish project at planned costs and time.
Very simple application (single programmer, tester - one man for all)
Requirements are simple and all known. If you are writing very simple application, using good architecture plan and code writing practices, as a result you should have clean ready to change application. Adding automated tests makes changes easier without software quality drop. You know all details without looking into documentation, and testing new changes and features during implementation. All changes go to the code repository with comments and TODO file.
Simple/medium, application (team of 1+ programmers and other stakeholders)
The requirements should be gathered and agreed before development. You are using some kind of Issue Management System, tracing all change requests. Application is divided into main modules referred in task details. Programmers know what to change and what are dependencies between modules and side effects of implemented changes. Testers know main modules, and are going through test procedures of modules and functionalities. Procedures are short and clean and there is a natural place for agile methodologies.
Large application, (team of 10+ programmers and stakeholders)
Application is quite huge. Preparing requirements is often separate project. Every change request is thoroughly reviewed then approved. Application have many interdependencies caused by re-usability and connection points. Some changes have strictly local effects for given feature, those are less harmful. Other change some lower level service, probably unit tested, but still having impact on bigger process. Automated tests are not covering every possible use of code, manual top level functional tests are last line of defense in quality assurance. In real life every module has many connections with other modules. Testers have very limited knowledge about those dependencies. Everyone needs more plans, documents, procedures and artifacts that is slowing down the whole process. Practical solution is to divide the large project into smaller, less complex sub-projects.
At this level of complexity there are many "process complete" management methodologies. The winning one is the best suitable for given project, reducing risks and allowing to finish project at planned costs and time.
Subscribe to:
Posts (Atom)
IT Pro Life
