To Prototype or Not to Prototype?

What is a software prototype?
A prototype usually simulates a few aspects of the functional requirements of the system under development and may be completely different from the eventual implementation.

Why do we use software prototypes?
As software engineers it is possible to use prototypes in order to be able to investigate concepts, visualize design options and help research alternative solutions for the problem on hand. A software prototype helps in many ways:

1. Having a prototype helps the elicitation of further system requirements. When customer stakeholders actually see a prototype, from experience, most of the times say that something is missing. This process is very helpful in validating system requirements.
   
2. User interface design is a key factor for the success of the software under developement. Presenting and collaborationg wirth end users using a UI prototype is a very nice way of producing widley accepted interfaces.
   
3. A prototype can be used in the testing process comparing it with the system to be delivered to the customer. That means, entering in both systems (prototype and application) the same data and compare the output results. If the results are identical then there is no fault detected. (Sommerville, 2006, p.409-410)
   

Although prototypes have great benefits for the software project, they hide some dangers. One major danger is to use a prototype and develop it further to a product. The prototype is for experiments and proof of concept. It has no “depth” or quality build in it.

Using a prototype can be viewed as a risk reduction process. This process may introduce new risks to the project if not handle carefully. Except the risk mentioned above there are also other risks involving the software prototype. The risks are:

1. The customer gets a wrong impression on the stage of development. Seeing a working prototype is confusing to him and thinks that the software is almost ready. It is of paramount importance not to let stakeholders to think of the prototype as an early version of the software system.
   
2. Users may confuse the hows of the user interface and not focus on what’s of the prototype. The prototype will be used to validate the requirements of the system and not how the system will look and how it will operate.
   
3. Users may believe that the prototype performance will be the end software product performance. It must made clear to customers that in the prototype are not any security features or optimized algorithms. A good habit is to use a delay timer to simulate the actual system response time.
   (Wiegers, 2003)

From personal experience I know that stakeholders confuse the prototype as an early version of the system. I was building hotel management software to handle the front office jobs of a hotel. I delivered a prototype to the customer soon after we had finalized the description of the software requirements. The prototype was to test what the menu navigation would be, what critical functions (reservations) the software will perform. After the demonstration of the prototype the customer refused to believe that it will take several months of development to finish the product. It took me several meetings with the customer to convince her that it was a prototype and not an early version of the software. Sometimes managing customer expectations can be very difficult.

As a conclusion software prototyping can reduce the ambiguity of functional requirements and shorten development schedules. We must include time in the project schedules for building several prototypes and state why we want to build them. (Wiegers, 2003)

From my experience even early prototyping screen mock-up on paper can help describe the requirements of a software project.

What software can be used to create prototypes?
I have used pencil sketching for Mozilla Firefox, I know that Adobe's Dreamweaver can be used for fast prototyping. An idea is also to use Iron Speed designer. There are many more tools listed in Cunningham & Cunningham wiki.

References

Sommerville, I (2006). Software Engineering. Addison Wesley / Pearson 8th Edition. ISBN: 0321313798

Wiegers, Karl E. (2003). Software Requirements, Second Edition. Microsoft Press. ISBN: 9780735618794

Animated database courseware (ADbC)

Learning database concepts is sometimes difficult and challenging. Animated Database Courseware (ADbC) is designed to support the teaching of database concepts. It is developed at Kennesaw State University. Areas covered include database design, SQL, transactions and database security. The animations are generic not tailored to any specific product or textbook.

In my opinion the tool offers good examples and covers most of the areas of modern database design. It has a good explanations of topics like transactions Concurrency, store procedure and functions, triggers.

B2B=BrainToBrain Communication

Dr. Cristopher James from the University of Southampton achieved for the first time Brain-to-brain communication.
For his experiment one person using Brain-Computer-Interface (BCI) transmitted thoughts, as a series of binary digits, over the internet to another person. The second person was attached also to an EEG. The PC would pick up the stream of binary digits and flash a LED lamp at two different frequencies, one for zero and one for one. The pattern of the flashing LEDS is too subtle to be picked up by the second person, but it is picked up by electrodes measuring the visual cortex of the recipient.

Here is Dr James' BCI experiment to watch.

As Dr. James said, B2B can be beneficial to people with severe debilitating muscle wasting diseases or with "locked-in" syndrome.

Insecure US drones are hacked with the 26$ SkyGrabber software

Wall Steet Journal: Iraq militants used SkyGrabber a 26$ software to intercepted live video feeds from U.S Predator drones. The U.S. military personnel in Iraq discovered the problem when they found a laptop of a Shiite militant which contained files of intercepted drone video feeds.
The capture of the feed was possible because the downlink between the unmanned craft and ground control in unencrypted. The solution is to add encryption to the system. The problems of adding encryption include a price increase on the drones and also interoperability problems between sharing of time-sensitive data within the U.S. military and with allies.

My comment is that this is a good security lesson to those that believe that unprotected data will be difficult to be discovered or that it is difficult to steal sensitive data which is transmitted without encryption.

Eliminate Risk from Software Engineering Projects

Uncertainty exists in every project. Where there is uncertainty there is risk. For a project, risk is an event or condition which if occur has an effect, either positive or negative, on at least one of the project dimensions. A risk event can affect scope, schedule, cost and quality of the project. There are two types of risks:

1. known risks and
2. unknown risks.

For a project to be successful risk management should be done early in the project planning. The plan risk management should identify the risks, perform qualitative risk analysis, perform quantitative risk analysis and plan risk responses. Defining a Risk Breakdown Structure helps to identify project risks. Typical categories where risk might occur in a project are technical, external, organizational and project management.

Shenhar (3) discusses the technological uncertainty for four types of projects: Low-Tech (ex. road building), Medium-Tech (ex. Existing product improvement), High-Tech (ex. New systems) and Super High Tech (ex. the Hubble telescope). Ways to reduce uncertainty involved design cycles and design freeze.

There are mainly three categories of risks relating to software projects:

Project Risks which affect the availability of resources or the time constrains of the project. From experience I know that usually developers are very optimistic when setting deadlines. They do not anticipate difficulties that may occur in the development phase of the project. This easily creates a problem with time and completion of the project. It has also implications with the total cost of the project.

Product Risks which affect the performance, scalability or the quality of the software under development. Again, from experience I know that is totally different a design that supports a few hundred users to one that supports simultaneously thousands of users. Creating multithreaded code and introducing locks into the system to avoid race situations involving shared resources increases the complexity of the code and complicates the testing of software components. I have more than 20 years of programming experience and I have seen good and bad quality code. I have also seen code that was fully commented, not well documented having no bugs but it was unnecessary complicated. This type of code can be spotted only from experience and the cause of it is job protection. Programmers thought that by writing code the way they did they were protecting their jobs because no one else would be able to deeply understand the code. In my opinion quality of the code cannot be counted by bugs and bug fixes as many organizations practice but with internal and external (if possible by an independent consulting firm) code reviews.

Business Risks which affect the business itself. For example a change in technology that a system assumed.

To have a plan ready to respond to risks that might occur, can save the project depending on the severity of the risk. The risks that are worst are the ones that are unknown and have an unknown outcome. There are several strategies available to reduce or control the risks:

• Avoidance. Taking proactive actions to avoid the occurrence of that risk.
  
• Transference. Insurance or subcontracting.
  
• Mitigation. Reducing the risk to an acceptable level for the organization
  
• Acceptance. Identifying the risk but making no plans to mitigate or avoid the risk.
  
• Contingency planning. Having an alternative plan to follow if a risk occurs.
  
• Independent verification and validation. A third-party oversees the project.

As a conclusion the most certain thing about projects is that risk factors will occur in one form or the other. Reducing or controlling the risk is a task that is performed by a team.

From experience I know that is also important to take under consideration the external environment when devising risk plans. This post is an introduction to possible risks associated with software development projects. I will continue with more in depth postings on the subject.

References

1. Heldman, Kim (2005). Project Manager's Spotlight on Risk Management. SYBEX
   
2. PMBOK(2008) A guide to the project management body of knowledge. PMI 4th edition.
   
3. Aaron J. Shenhar (2001) “One Size does not Fit All Projects: Exploring Classical Contingency Domains” Management Science, Vol. 47, No. 3 (Mar., 2001), pp. 394-414 INFORMS
   
4. Sommerville, I (2006). Software Engineering. Addison Wesley / Pearson 8th Edition.

Software system requirements review

Software system requirements are describing:

• the system to be build
• its functions
• its purpose

Requirements are used to define these constraints and articulate beyond any misinterpretation the software system to be build.
The term "requirement" is used very broadly in software systems. It includes:

• the Functional Requirements,
• the non-Functional requirements
• the domain requirements.

The Functional requirements state what the system should do and what the system should not do. Meaning how the system will handle input and what output to produce.
The non-Functional requirements describe attributes of the system as a whole. To give an example, a non-Functional requirement may be the response time of the system to user requests.
Domain requirements are derived from the application domain. This means that the software system might comply with some international standards.

I think that it is important to use a categorizing schema in order to be sure that all requirements are covered and to reduce the risk of not considering some important aspects of the system.
FURPS+ is used in Unified Process to categorize requirements. FURPS stands for Functional,Usability, Reliability, Performance and Supportability. The + stands for Implementation, Interface, Operations, Packaging and Legal.

It is very important to validate requirements after defining them. Correcting requirements during a requirements review has a small cost for the project. If errors to the requirements are found in later stages of software developement the cost to correct them is much bigger.

Stakeholders of the system may have different needs from the system and sometimes these needs may be conflicting. Thus, it is important to perform validity and consistency checks to the requirements. The customer and the software development team should review the requirements to ensure that the requirements correctly describe the system to be build. All the requirements of the system should be verifiable and comprehensive. It must be clearly stated who enforced a requirement in order to be able to trace back to the originator in case of a requirement change. For each requirement is good practise to state the adaptability of the requirement, meaning what the effect on the system will be if the particular requirement is changed.

After the requirements are reviewed and the proper use cases are written along with all the documentation to describe the system a requirements management system must be activated in order to:

• Control changes to the requirements in a systematic way
• Keep in synchronization project plan with requirements
• Track the status of the requirements
• Ensure that all team members have correct latest version of the requirements.

It is very important to have a conflict resolution procedure to detect and reolve conflicts. Stakeholders must have active involvement in change requirements interaction. Monitoring change and active stakeholder involvement greatly reduces system errors and increases stakeholder satisfaction and system effectiveness.

As a coclusion it is important to walkthrough the customer through the system using use cases and scenarios discussing all requirements. It is also important to insist that domain experts be present to correclty identify the requirements of the system.

References

Larman Greg(2002). Applying UML and Patterns:an introduction to object oriented analysis and design and the Unified Process. Prentice Hall 2nd ed.

Robinson,W.N, Pawlowski, S.D, and Wolkov, V(2003). Requirements interaction management. ACM comput. Surv. 35,2 pp. 132-190. DOI=http://doi.acm.org/10.1145/857076.857079

Sommerville,I (2006). Software Engineering. Addison Weasly/ Pearson 8th edition.

Wiegers, Karl E.(2003). Software Requirements, Second Edition. Microsoft Press

Web hosting - Domain Name registration

I was busy lately and I am behind my postings. I have a list of very interesting subjects.
I was creating a new online venture. It is about web hosting and domain name registration. I was searching for long time to find the correct combination and I believe I finally found it!
You can take a look at http://www.123easysites.eu/ .
I want to offer web hosting at affordable prices without sacrificing reliability.
Please feel free to drop a comment or suggestions.
I hope that now that the site came alive to find some spare time and move my blog to its own space.

High performance distributed data storage systems

In the online edition of ACM Communications Sept. 2009 Issue I read a very interesting article from Michael Stonebraker’s blog about the end of RDMSs. I did a little research and I found that the distributed key-value stores are gaining ground especially in Web based applications. Many sites such as Amazon, LinkedIn, Yahoo, Facebook use distributed key – value stored to cope with petabyte data.

From the braindump blog I saw that there is a fast growing noSQL community that talks about how distributed non relational databases work.

A very interesting paper is the presentation of Amazon’s Dynamo highly available key-value storage system. From Amazon’s experience we learn that the reliability and scalability of a system is dependent on how its application state is managed.

For some quick links:

Hypertable is designed to manage the storage and processing of information on a large cluster of commodity servers, providing resilience to machine and component failures.

Cassandra is a highly scalable, eventually consistent, distributed, structured key-value store.

Voldemort is a distributed key-value storage system. In the “Build and Break” blog there is a nice post about the Voldemort project.

CouchDB is a document database server, accessible via a RESTful JSON API.

Mongo (from "humongous") is a high-performance, open source, schema-free document-oriented database.

Quality Management Systems

When a company implements and follows a quality management system it obtains a minimum level of quality. Having a quality management system in place guarantees that the company will make the same mistakes each time it runs its processes. This way the company can spot and correct its processes.

ISO 9000
ISO 9001 specifies the basic requirements for a quality management system (QMS) that an organization must fulfill to demonstrate its ability to consistently provide products (which include services) that enhance customer satisfaction and meet applicable statutory and regulatory requirements. The standard can be used for certification/registration and contractual purposes by organizations seeking recognition of their quality management system.
Many potential customers require that the development company has an ISO certificate before they will award it a contract. This holds both for government agencies and for private companies. The main reason for this is the level of trust created by an ISO 9001 certificate. It is much easier to check that the company has an ISO 9001 certificate than it is to check that they have a good development process and, if they have one, that they really follow it.

CMMI and ISO

CMMI determines maturity whereas ISO is based on conformity.

The CMMI is 729 pages, the ISO is 33 Pages

The ISO is more flexible and cheaper.

CMMI is easier to claim (considering maturity). CMMI more appropriate for software, systems, product development.

ISO 9001:2000 explicitly addresses customer satisfaction, while CMM assumes that adhering to the requirements of the various key process areas implicitly leads to higher customer satisfaction.

ISO 9001 Maps in most cases to CMMI and vice versa. Certification for ISO can help an organization also to get certified on CMMI level2 by filling the missing gaps between the two systems.

ISO implementation
For a successful implementation of a QMS these 7 steps are recommended:

1. Fully engage top management to:

• Define why you want to implement ISO 9001
• Define your mission, vision, and values in your organization
• Define your organization’s stakeholders: customers, suppliers, stockholders, employees, society, etc.
• Define your quality policy, and
• Define and align organizational objectives and related product/service quality objectives

2. Identify key processes and the interactions needed to meet quality objectives

3. Implement and manage the QMS and its processes (using process management techniques)

4. Build your ISO 9001-based QMS

• Identify ISO 9001 requirements
• Map these requirements with your implemented QMS, where applicable
• Make a gap analysis: identify where in your existing system the requirements are fulfilled, and where they are not
• Include in your QMS processes the activities, procedures and controls needed

5. Implement the system, train company staff and verify effective operation of your processes

6. Manage your QMS

• Focus on customer satisfaction
• Monitor and measure the operation of your QMS
• Strive for continual improvement
• Consider implementing business excellence models in the company operations

7. If necessary, seek third party certification/registration of the QMS or alternatively, issue a self-declaration of conformity.

I have implemented ISO 9001 and I have worked with CMMI. My experience with ISO being an internal quality inspector was very positive. The system helped reduce the operating costs of the company by 15%.

References

Platinum Registration (n.d) CMMI and ISO 9001 Available from: www.platinumregistration.com/kbfiles/ISO9kCMMIDiffernces.ppt

ISO (2008). ISO 9000 and ISO 14000. Available from: http://www.iso.org/iso/iso_catalogue/management_standards/iso_9000_iso_14000.htm

Boris Mutafelija & Harvey Stromberg (2003). ISO 9001:2000 – CMMI v1.1 Mappings Available from: www.sei.cmu.edu/cmmi/adoption/pdf/iso-mapping.pdf

Christ Vriens (2003). Certifying for CMM Level 2 and ISO9001 with XP@Scrum. Philips Research - Software Engineering Services (SES). Available from: Proceedings of the Agile Development Conference (ADC’03) DOI: 0-7695-2013-8/03