User Interface Prototype

The user interface prototype is built early, before the whole system is analyzed, designed and implemented.

The main purpose of creating a user-interface prototype is to be able to expose and test both the functionality and the usability of the system before the real design and development starts. This way, you can ensure that you are building the right system, before you spend too much time and resources on development.

The Prototype must be significantly cheaper to develop than the real system, while having enough capabilities to support the meaningful functionality.

What it does not contain.
- No code to connect to the layers below.
- No Graphics
- No standards implemented.
- May not have complete data. Has some dummy hard coded data to communicate.
Remember, UI prototype goes through several refinements and changes several times. It helps the users feel and give feedback. It acts as a validation to the use cases. Hence, it is not important to use the right standards or have graphics, or code behind. These are taken care during the design.

Once the UI prototype is approved by the customer, it should be treated like a requirement and CM controlled. Any changes to the prototype should go though an approved process using change request mechanism.

From the experiences, developing UI prototype early on is a differentiator between a successful project and not so successful project.

Financial Structures in software projects

To ensure effective management of capital investments in software projects a good financial structure is essential. With the current trend in outsoaring, this aspect is even more important.
The capital budgeting models need to take into consideration the managerial flexibility available to the organizations. For instance, depending on the risks, the manager can decide to cancel or change the course of direction of the software project.
One of the successful ways of doing this is a phase based approach. During the first phase, the software project budget is approved only to define a vision, scope and achieve concurrence among all stakeholders. The primary focus is to address significant business and requirements risks which must be addressed. Based on the results of this phase, reevaluation of the business case is made and the budget for the next phase is approved for mitigating the architectural risks that have great impact on the system. Following the demonstration of the architecture that mitigates the risks a further reevaluation of the business case is done to make sure the return on investment is still good. At this point, the estimation for the software project budget is much clearer as the bigger risks are already mitigated and budget for developing the operational system can be approved.
This systematic approach to managing the risks and return on capital investments puts good financial controls and monitors through out the life of the software projects.
Spiral models available for developing the projects allows the managers and CFO’s to implement this type of mechanisms In the case of outsourcing, these structures provide a greater contractor control and a bonus payment scheme at each phase could be given for better results. Organizations will have better control to change the course of direction or to change the financial control will encourage good performance by the contractor.
As a side note, from the contractor’s perspective a time and material type contact until the risks are mitigated (during the first two phases) is beneficial. Overall, this approach would be a win-win for both parties.

Testing, Testing and more Testing

Testing, Testing and more Testing should be one of the mantras for success. In general, managers involve during the initial stages but mostly ignore the testing stage. Every manager need to put controls and facilitate using the right processes to ensure that enough testing is done.
All the Managers in the hierarchy should get involved with the testing activity. For example, development managers should review the test scripts and facilitate to ensure the testing is done appropriately. A divisional manager should get involved in reviewing the test plan and reviewing the summary of the test results to ensure that adequate testing is performed.
More often testers are under appreciated and viewed as people who delay the delivery of the system. In reality, testers help the development team to deliver a better quality product. Testers really make the development team look good in front of the customer by providing services to find the bugs (mistakes if we can call) in the systems built. In occasions where the testing was not part of the core processes the module leads scrambled to deliver the product with minimal testing and often worked as Silos with little integration testing. Processes that took into consideration testing at different levels (Unit, Integration, Regression, System etc) had better product delivery and led to reduced costs. (“Bugs found at earlier stages are less costly than the bugs found in later stages”).
Testing activity should be started as early as possible. A test plan could be created during the beginning of the project and test scripts written even before the first line of code is written. An automation of the test scripts could take a long way in performing regression testing easier.
In one occasion, publishing the daily bug report produced by the testing team and made visible to all the employees in the division acted like an incentive to development managers who had fewer bugs. In return this approach has drastically improved the quality of the product.
While it is impossible to develop a system that is bug free, testing activity can take you closer to that goal.
Most importantly, testers need to be appreciated for the services and view them as people who are helping the development to look better.

Termites not Tornadoes

Software projects often slip schedules, have cost overruns and have bad quality due to small events that occur each day rather than by big events. The project slips one hour, one day at a time, and the cost overruns happen one dollar at a time. Often it is human nature for people to jump in and help for big events while ignoring the small events. However, small issues occur more often than the big events and can have a stronger negative effect if not addressed.
Project team members should give importance to the issues that occur repeatedly to avoid repeating mistakes. Earned Value is a tool available to project managers that could help in tracking these overruns early on.

Reviewing Workproducts

It is important to have workproducts that needs to be reviewed in the review meeting sent out to the reviewers in advance and have the reviewers provide comments before the meeting. This will save plenty of time during the review meeting and gives everyone an opportunity to provide good feedback. Having a moderator (separate from the author) to read the comments sent out, update the comments in the meeting and later ensure that the accepted comments are incorporated takes the reviews to the next level. Having a website/common place where reviewers can start a thread for comments (with a status of the comment) will be even more efficient.

Software Configuration Management

Software configuration management is essential for projects of all sizes. The need for one increases as the size of the project increases (i.e. exponentially correlated). In large projects configuration management takes care of the confusions caused by simultaneous updates, problems due caused due to not notifying all the developers and multiple versions created by evolutionary releases.
Software configuration management is no doubt one of the valuable software engineering processes. It is a combination of using the right tools and making the people use the right way. It is more than providing an insurance for backups. It is not just for backup and having the ability to get a previous version. In team environment, it provides control for baselining, promotion of builds, views, parallel development, provides automation and consistency to the build process, subcontractor control and provides a means for auditing. Using good standard procedures allows automation, simplifies and ensures the integrity. For example the artifacts produced could be posted to the portals from the version control system automatically at the end of the project. Similarly an automated build and installation process like the model mentioned at Microsoft could be achieved.
For organizations trying to get CMM level certifications and implement the ri the methodologies the first step is to look at the SCM plan and ensure that these are standardized.

Knowledge vs process

Organizations may view well defined processes/methodologies will help them even if they are not strong in the core disciplines. However, understanding of how to do the core disciplines (Project Management, data modeling, business modeling, OO modeling, testing, CM etc.) is vital and implementing any methodology will not help. In order to achieve good results organizations need to take this into consideration during the implementation of new processes.

Waterfall to Iterative

Iterative development requires a different way of thinking compared to the traditional waterfall model. It requires changes for several groups (Infrastructure, Management Review committees, Release, QA and Production support) supporting/enabling the development organizations. These groups need to get involved at every level rather than at the end and requires changes in the current processes. Often these groups are gatekeepers and resist change in the fear of losing control. While in fact, the controls are in place as a detection points at an earlier stage and still exists as enforcement at a later stage.
Communication and outreach program are important aspects of implementing a new software process at an organization level. Change in the process can be made more easily when the employee buys into the new process. This requires considerable effort to be put in reach out to the individuals and helping employees understand the benefits. A Transition Plan that contains different levels of adopting the new process avoids the big bang effect. Using an Itertative incremental model to implement itself is a good approach