Software Development best Practices and Processes

More on Prototyping

noreply@blogger.com (Ravisat) — Thu, 01 May 2008 12:40:00 +0000

Who should be involved, how far you should go and when do you have to do Prototyping during Software Development?
1. Who is Involved?
Prototyping can be done informally by anyone, regardless of their background or role in the project. It’s easy to make a simple but effective prototype by taking a bitmap from Adobe Photoshop, putting it into the Microsoft FrontPage Web site creation and management tool, and adding active buttons or links. These lightweight prototypes only go so far, and can become unwieldy for complex interactions.

For more formal prototypes by larger teams, a developer or project manager will often collaborate with a designer and a usability engineer. Together they’ll generate ideas, build a prototype that represents the best ideas, and then go into the lab to see how effective it is in solving user problems. Developers might get involved if they can spare the time, or if their technical expertise is needed. Often the designer or project manager will do most of the scripting or coding to build the prototype.

2. When Do You Build a Prototype?
Depending on the scope of the prototype and the level of detail required, prototypes can be built at any time during the project. Most often they are created early in the project, during the planning and specification phase, before developers write any production code. That’s when the need for exploration is greatest, and when the time investment needed is most viable. If developers instead of program managers or designers are prototyping, scheduling time becomes even more important because you need to make sure the work invested in the prototype is accounted for in the development schedule. Planning for any UI release should include some level of prototyping.

Late in a project, smaller prototypes can help resolve tough design and technical issues. A quick HTML mock-up of how a dialog box or Web page should behave can help answer a developer’s question or give other teammates a feel for what the desired experience should be. In some cases, a strong program manager or designer can implement the behavior in Microsoft JScript development software and approximate much of the programming logic that developers will need to think through.

The time it takes to create a prototype can vary tremendously, depending on the scope and precision of what the end result needs to look like. An informal prototype could mean a few hours of work by one person; a more organized effort can involve weeks of effort by an entire team.

3. How Far Should You Go?
In your prototype, build only as much of the design as you need. It’s okay to have buttons that don’t work, or text that never updates. As long as you can experience the interactions you want to explore, it’s fine to use smoke and mirrors for the rest. Here are a few reasons why you should focus your efforts carefully:

3.1 Cost of building the prototype.
You want to minimize the cost involved in building the prototype. The challenge with prototyping is recognizing the minimal investment needed to effectively answer your questions about the design. This is where usability studies are critical, because they clearly identify the parts of your UI that need the most work. Even without usability studies, you should clearly define what user problems you’re trying to solve, or what tasks you’re trying to improve, with the design in your prototype.

3.2 Limited lifetime.
Prototypes should have clearly defined lifetimes. Is the end goal a presentation at a team meeting? An executive review meeting? A spec review? A usability study? Convincing yourself, with your devil’s advocate hat on, that the design solves a user problem? Once the needs for these specific objectives are met, the prototype should be set aside. The basic mindset is that the code or bitmaps generated in a prototype will be left behind. There might be exceptions where code or visuals live on in the product, but the expectation should be that this won’t be the case.

3.3 Risk of overwhelming the team.
Showing prototypes to developers and teammates can be tricky. An overly complex or elaborate prototype, sporting amazing visuals and animation, can overwhelm people. You should always have a sense for how far to go and how much of what you’re creating in the prototype you want to be taken seriously.

For more information check the following resources
Offshore Software Development Services
Software Development Blogs

Requirements Development

noreply@blogger.com (Ravisat) — Sat, 26 Apr 2008 04:54:00 +0000

Tasks that must be done during Requirements Development

The purpose of requirements development process is to establish a documented common understanding of customer needs, intended product use, and needed software capabilities.

The result of this process is an organized set of requirements for a software product development effort that:

· Supports the customer’s needs, goals, and objectives

· Supports tracking and recording of costs and efforts

· Identifies the necessary resources and constraints

· Develops a software requirements specification.

Follwing are the high level activities that must be performed during a Requirements Development Phase during Software Product Development

1. Analyze High Level Requirements.

· Examine, discuss, and understand the high level requirements.

· Identify the scope of the requirements, the purpose of the software and analyze any constraints (e.g. budget, schedule or performance) affecting the software requirements.

· Identify and describe various activities end user will perform on the product

· Identify technological opportunities where the product will add value for better potential.

· Balance requirements scope to remain within programmatic constraints.

· Identify Quality of Service and functional requirements.

· Elicit stakeholder needs, expectations, constraints, and interfaces for all phases of the product lifecycle.

Use appropriate eliciting techniques for this purpose.

Examples of eliciting techniques can be:

A. Planned meetings with different customer process/product group owners

B. Planned meetings with the end users including end customers

C. White board sessions

D. Brain Storming

E. Reviewing competitors products

F. Past product feedback/shortcomings

G. Knowledge base

2. Document Quality of Service and Functional Requirements

· Describe the quality of service and Scenario requirements in the SRS document but leave the design to the architect and developers.

· If the brief description is not sufficient for complete understanding, write a more detailed form of the requirement in a separate requirements document, providing goals and rationale.

3. Verify Final Requirements and Specifications ·

· Conduct requirements peer’ reviews to ensure agreement regarding the intent and purpose of each requirement.

· Clarify ambiguous requirements.

· Determine the technical feasibility of each requirement and any risks inherent in approaches.

· Verify consistency, necessity, and completeness both internal to the requirements and against the requirement documents

· Develop prototype as required.

4. Validate Final Requirements and Specifications.

· The Business Analyst and Project manager review each requirement item in the context of the user domain to validate that all items adequately represent the user problem to be solved. If an item is not valid, it is revised so that it is valid.

· Review each item for the following characteristics.

i. Each item can be traced to its origin in the user's problem domain.

ii. Each item satisfies a specific part of the problem solution

iii. Each item can be implemented with the available techniques, tools, resources, and within cost and schedule.

iv. There is a single interpretation for each item, and the meaning is easily understood.

v. No item conflicts with another item.

vi. Each item is testable.

· Determine and document the method of validation to be used for each requirement.

· Conduct a Software Requirements Review to present the requirements to all stakeholders.

· Collect and track issues resulting from the Software Requirements Review as Requests for Action.

· Update the requirements as necessary to address the Request for Actions

5. Provide Roadmap / effort estimation for the product

· Document the effort required for development of this project

· Provide the resource plan and timelines to implement the product

· Provide approximate costs

6. Obtain Approval.

· Obtain signed approval to proceed with development.

· Baseline the requirements and specifications.

Following the above tasks in a tailored fashion that suits your requirements gathering needs will help create Software Requirements Specifications (SRS) that is detailed enough to help project teams to carryout the next steps in the Software Product Development.

For more information check the following resources
Offshore Software Development Services
Software Development Blogs

Decision Analysis and Resolution

noreply@blogger.com (Ravisat) — Sat, 26 Apr 2008 04:18:00 +0000

Structured Approach for Decision Analysis and Resolution (DAR)
In the course of work that we do, we are often required to select a solution from the various alternatives required. It becomes more difficult under situations where the risk involved is high and the experience for that situation is low. Also the consistency of decisions taken cannot be ensured.

This guideline explains a structured approach for decision making to resolve such issues.
Evolving a structured decision making process will help us in
· Taking better decisions
· Reduce the risk
· Institutionalise the approach.

Apart from the above benefits it will also help us bring in a rigour of objectivity using quantitative and qualitative approach in decision-making. It will also enable us to utilise the available information and experience.

However structured decision-making is not required for all decision making scenarios.
Structured decision making approach can be effectively used under the following circumstances –
· Areas where risk is very high related to Cost, Schedule & Effort. The threshold limits on the risk exposure, probability and impact will be decided at the project level.
· Where the decision affects the projects set Objectives
· Where the impact of the decision to be taken is large compared to the effort spent on taking a structured decision.
· Where the decision to be taken for cases, without prior experience or data is not available.

Here are the Examples of some areas where DAR can be applied
Based on the guidelines, following major areas have been identified where structured decision making approach will be used but they are not limited to.

·Project Management
o Estimate Size and Effort for new Domain and Technology
o Deciding on the Off shoring of Maintenance projects

Arriving at Testing Strategy
o How to decide on the testing strategy
o How to decide on the testing team composition.

Deciding on the Architecture/Technology
o How to decide on the product for a particular architecture service.

Tools procurement / build
o In a project there is a requirement for a tool for regression testing automation. Should they buy a COTS product or should they develop a tool for that. ?

Deciding on Hardware related issues
o To decide on the network link like shared link or direct link with the customer.

For more information check the following resources
Offshore Software Development Services
Software Development Blogs

Tips in UI Prototyping

noreply@blogger.com (Ravisat) — Thu, 17 Apr 2008 14:57:00 +0000

Tips and Techniques in User Interface Prototyping in Software Product Development

The following tips and techniques should prove valuable during the prototyping phase of your SDLC, these can also be used as guidelines, best processes and practices for User Interface Development:

Consistency, consistency, consistency. Most important thing you can possibly do is ensure your user interface works consistently. If you can double-click on items in one list and have something happen, then you should be able to double-click on items in any other list and have the same sort of thing happen. Put your buttons in consistent places on all your windows, use the same wording in labels and messages, and use a consistent color scheme throughout. Consistency in your user interface enables your users to build an accurate mental model of the way it works, and accurate mental models lead to lower training and support costs.

Set standards and stick to them. The only way you can ensure consistency within your application is to set user interface design standards, and then stick to them. You should follow Agile Modeling (AM)’s Apply Modeling Standards practice in all aspects of software development, including user interface design.

Be prepared to hold the line. When you are developing the user interface for your system you will discover that your stakeholders often have some unusual ideas as to how the user interface should be developed. You should definitely listen to these ideas but you also need to make your stakeholders aware of your corporate UI standards and the need to conform to them.

Explain the rules. Your users need to know how to work with the application you built for them. When an application works consistently, it means you only have to explain the rules once. This is a lot easier than explaining in detail exactly how to use each feature in an application step-by-step.

Navigation between major user interface items is important. If it is difficult to get from one screen to another, then your users will quickly become frustrated and give up. When the flow between screens matches the flow of the work the user is trying to accomplish, then your application will make sense to your users. Because different users work in different ways, your system needs to be flexible enough to support their various approaches. User interface-flow diagrams should optionally be developed to further your understanding of the flow of your user interface.

Navigation within a screen is important. In Western societies, people read left to right and top to bottom. Because people are used to this, should you design screens that are also organized left to right and top to bottom when designing a user interface for people from this culture? You want to organize navigation between widgets on your screen in a manner users will find familiar to them.

Word your messages and labels effectively. The text you display on your screens is a primary source of information for your users. If your text is worded poorly, then your interface will be perceived poorly by your users. Using full words and sentences, as opposed to abbreviations and codes, makes your text easier to understand. Your messages should be worded positively, imply that the user is in control, and provide insight into how to use the application properly. For example, which message do you find more appealing “You have input the wrong information” or “An account number should be eight digits in length.” Furthermore, your messages should be worded consistently and displayed in a consistent place on the screen. Although the messages “The person’s first name must be input” and “An account number should be input” are separately worded well, together they are inconsistent. In light of the first message, a better wording of the second message would be “The account number must be input” to make the two messages consistent.

Understand the UI widgets. You should use the right widget for the right task, helping to increase the consistency in your application and probably making it easier to build the application in the first place. The only way you can learn how to use widgets properly is to read and understand the user-interface standards and guidelines your organization has adopted.

Look at other applications with a grain of salt. Unless you know another application has been verified to follow the user interface-standards and guidelines of your organization, don’t assume the application is doing things right. Although looking at the work of others to get ideas is always a good idea, until you know how to distinguish between good user interface design and bad user interface design, you must be careful. Too many developers make the mistake of imitating the user interface of poorly designed software.

Use color appropriately. Color should be used sparingly in your applications and, if you do use it, you must also use a secondary indicator. The problem is that some of your users may be color blind and if you are using color to highlight something on a screen, then you need to do something else to make it stand out if you want these people to notice it. You also want to use colors in your application consistently, so you have a common look and feel throughout your application.

Follow the contrast rule. If you are going to use color in your application, you need to ensure that your screens are still readable. The best way to do this is to follow the contrast rule: Use dark text on light backgrounds and light text on dark backgrounds. Reading blue text on a white background is easy, but reading blue text on a red background is difficult. The problem is not enough contrast exists between blue and red to make it easy to read, whereas there is a lot of contrast between blue and white.

Align fields effectively. When a screen has more than one editing field, you want to organize the fields in a way that is both visually appealing and efficient. I have always found the best way to do so is to left-justify edit fields: in other words, make the left-hand side of each edit field line up in a straight line, one over the other. The corresponding labels should be right-justified and placed immediately beside the field. This is a clean and efficient way to organize the fields on a screen.

Expect your users to make mistakes. How many times have you accidentally deleted some text in one of your files or in the file itself? Were you able to recover from these mistakes or were you forced to redo hours, or even days, of work? The reality is that to err is human, so you should design your user interface to recover from mistakes made by your users.

Justify data appropriately. For columns of data, common practice is to right-justify integers, decimal align floating-point numbers, and to left-justify strings.

Your design should be intuit able. In other words, if your users don’t know how to use your software, they should be able to determine how to use it by making educated guesses. Even when the guesses are wrong, your system should provide reasonable results from which your users can readily understand and ideally learn.

Don’t create busy user interfaces. Crowded screens are difficult to understand and, hence, are difficult to use. Experimental results show that the overall density of the screen should not exceed 40 percent, whereas local density within groupings should not exceed 62 percent.

Group things effectively. Items that are logically connected should be grouped together on the screen to communicate they are connected, whereas items that have nothing to do with each other should be separated. You can use white space between collections of items to group them and/or you can put boxes around them to accomplish the same thing.

Take an evolutionary approach. Techniques such as user interface prototyping and Agile Model Driven Development (AMDD) are critical to your success as a developer.

For more information check the following resources
Offshore Software Development Services
Software Development Blogs

CMMi Specific and Generic Practices

noreply@blogger.com (Ravisat) — Sat, 12 Apr 2008 07:40:00 +0000

Process Areas, Specific and Generic Goals, Specific and Generic Practices

There are a lot of Specific and Generic Practices that need to be fulfilled in order for a organization to be appraised at any level of CMMi.

Attached is a document that is a consolidated list of all the Specific and generic Practices that are applicable at CMMi Level 3. This is based on Ver 1.2 of the CMMi Model.

The structure is that the process areas are divided into 4 areas - Engineering, Project Management, Support and Organization level process areas.

Each of these process areas have specific and generic goals to be achieved and each of these goals in turn have some specific and generic practices that need to be implemented.

Evidences need to be gathered and certain artifacts need to be produced in order to show the direct and indirect evidences if the organization is going for a SCAMPI appraisal.

This document has place holders for Procedures, Forms, Guidelines, Checklists, Templates and Training material that can be created at each specific or generic practice level. On completing this excel sheet, an organization can do a self gap analysis in order for them to check where they stand in terms of process maturity that is compatible with CMMi Level 3 ver 1.2.

This document can also be a good input once the need of maintaining PIID arises during SCAMPI appraisals.

Silicus has used this and lots of other documents during their process maturity journey and has successfully achieved CMMi Level 3 (staged representation) for Software Product Development and Sustenance life cycle methodologies.

Download the document CMMi Specific and Generic Practices

For more information check the following resources
Offshore Software Development Services
Software Development Blogs

Tools and Technologies in UI Prototype

noreply@blogger.com (Ravisat) — Sun, 06 Apr 2008 17:57:00 +0000

Tools and Technologies that can be used in Usability Engineering, prototyping during Software Development

There are several different tools and technologies you can use for creating prototypes, each of which has its advantages and disadvantages. Consider the type of design work you’re trying to prototype and the goals of your prototyping effort as you decide which tool or technology is right for you.

Paper - For usability studies or quick reviews, paper is often the fastest way to prototype a design idea. Using Photoshop, mspaint, or any tool you are comfortable with, produce screens that express the design, and print them out on paper. If you make enough screens, you can simulate walkthroughs, allowing test users to make choices and experience the design. However, for prototypes of moderate complexity, generating paper prototypes can be cumbersome. Highly interactive things like games or chat rooms can not be simulated well on paper. Also, the more elaborate the tasks, the more pages you might need to have handy.

Microsoft .NET. This is the fastest technology for creating Windows-style and Web based UI prototypes. The Web browser object makes it easy to integrate HTML UI with your standard Windows-style components. While it’s true that an experienced C/C++ developer might be able to generate UI faster in C/C++, this creates the temptation to reuse code from the UI prototype in your production code. It takes discipline to recognize that the goals of a quick and dirty UI prototype are highly divergent from high-quality engineering. Make sure you know what kind of code you’re writing, and that your team or manager understands what will be discarded.

Macromedia Director or Flash. This is one of the most popular UI prototyping tools among designers. It is most useful for multimedia or non-standard GUI designs, or for prototypes that require significant animation. It’s high flexibility makes it cumbersome for Windows-style UI compared to Visual Basic. However, a proficient Director user can generate Windows or Web UI without difficultly.

HTML. Dream weaver, FrontPage and other HTML editors allow for fast creation of simple prototypes. To express an idea, you can often create bitmaps that illustrate a sequence of user interaction, and place them into FrontPage. Then you can create link areas to connect the pages, and simulate how you can interact with the design. JScript and DHTML take things to another level, allowing for very sophisticated logic and interaction. If you are using HTML to prototype your Web site, the warning just described for C/C++ applies here as well don’t fall into the trap of confusing quick prototype code with production-quality engineering.

Ajax - This is the latest technology that uses Web 2.0 concepts to create user friendly presentation Layers, with this you can break up the page/screen into a variety of small UI elements, like a header, a navigation menu, a sidebar, etc and then we should be able to create reusable snippets of code

Also, most importantly by using Ajax in prototyping, you are prepping up the site for web Application Integration. The general structure of an Ajax prototype is remarkably similar to the structure to how a Engineer would incorporate the design into a web Application framework. They don’t have to dig through endless lines of presentation code, rather each function is nicely separated into it’s own HTML file.

More articles on usability engineering in software development will come shortly ...

For more information check the following resources
Offshore Software Development Services
Software Development Blogs

Software Development for Small Projects and Shorter releases

noreply@blogger.com (Ravisat) — Fri, 28 Mar 2008 11:16:00 +0000

Process for delivering on small projects or shorter release cycles in Software Development

At Silicus our service offerings are geared to deliver software via different development methodologies that cater to full life cycle development projects and maintenance life cycle projects. Apart from executing projects in traditional waterfall our quality processes are matured in executing projects in iterative waterfall methodology OR what is being termed as agile methodology.

We tend to look each of our projects from different stakeholders perspective and customer being the important one. And to cater to the changing situations during product development we are shifting and also recommending Agile as a suitable methodology to our customers.

We are familiar with different agile methodologies and the most important one being SCRUM and MSF. Here is a perspective of how we can adopt these agile methodologies in cases where there is a need for shorter release cycles. We will not get into the details of a particular agile methodology, but it is more for how our Quality Management System is capable of handling small projects OR Shorter release cycles.

We work on a team based model during the entire life cycle activities and these have different advocacy groups that cater to specific responsibilities during the Software Development Life Cycle. These advocacy groups derive responsibilities based on our Life cycle models that are established for Full Cycle or Maintenance projects. There are 4 important classifications of our Quality Management System that will be referred to during the execution

1. Project Management – Takes care of the project management, planning, estimation, monitoring and control, risk management, issue resolutions
2. Engineering – Covers all the technical aspects during the SDLC
3. Support – takes care of adherence to these processes, configuration management, metrics collection and analysis
4. Organization – ensures proper guidance at all levels, assigns responsibilities, addresses tailoring needs, identifies training and provides organization repositories

The applicability of the above with respect to smaller projects in Offshore software development is mentioned below.

Project Management
· For small projects we follow agile methodology – specifically SCRUM, unless the customer recommends some other methodology
· We will evaluate if the execution of small projects is based on a distributed development or not
· If it is on a distributed development environment – we use our Integrated program management process and guidelines to establish the common set of tools, environments, different groups collaboration issues and standard work environments
· We use our project initiation process to setup the above for a single development environment
· The above two activities are done only the initial time and this helps for the platform to be ready for rapid development
· We define a project management plan for small projects that will be maintained and controlled by the product/project manager
· We agree on to a communication and status reports format that will be followed by everyone
· The key to success for project management advocacy group on shorter cycle is to have a frequent communication with the customer sponsor and the involvement from customer sponsor is high in these cases. · The primary role of project manager in these kinds of development is more to manager the scope of deliverables, issues than managing people
· Our people are groomed to deliver in such a kind of environment and the expectations set with them is such way that they have to manager themselves and have to be very agile in bringing up the issues and risks at the right time
· Daily meetings will be mandated as part of the execution cycle and everyone must and will participate to report the progress and issues if any
· Project manager gets the status on a day to day basis and it will be his/her responsibility to communicate this status to customer and accordingly take decisions/prioritize deliverables for the success of the iteration.
· The goal is to have the end customer get the benefit at the end of each agile iteration / Sprint.
· The tools and templates that we adopt are geared for delivering for such kind of shorter release projects
· Each task or a set of tasks will be treated as a mini-project and module and will accordingly be monitored and controlled

Engineering
· For small projects, small tasks we do not expect to go through a formal requirements analysis or a detailed estimation and scoping exercise
· We would like to get the KT of the project that we are working on so that the team can understand the tasks and also establish the development/test environment (one time)
· We would like to get the tasks in a defined format – Enhancement/Feature request form, that will address the all the information that a developer requires to implement the design/development
· Project manager will be responsible for coming out with feature request after discussing/prioritizing the task with customer.
· Project manager can use our internal tools for entering these inputs – and it is not required to maintain a document for each request
· Based on the priority of customer the work on these tasks can be kept on hold and new work can be started.
· Where there is a need for design/prototype in tasks, appropriate reviews/approval process will be scheduled to handle the same
· Testing requirements and scope will be part of each feature request.
· A parallel set of testing team can be in place to do the testing of these features towards the end of each iteration.
· A standard release process will be followed and appropriate controls like code check in, release notes will be in place
· Team will be on standby if required whenever there is a release to a production environment
· Continuous integration server tools will be used for better configuration control, build activities

Support
· A frequent check point (generally at the end of iteration) will be established to see the performance of the iteration and the lessons learned during that iteration
· Data will also be gathered to analyze the number of features that were actually delivered
· Project will discuss the backlog of features with customer and accordingly plan the set of features to be developed for the next iteration – an internal process will be established to provide the reason for the backlog
· Proper configuration management activities will be performed to ensure data integrity and appropriate backup, recovery mechanisms in case of a need

Organization
· Where there is any need for new hardware and software requirements, the organization support staff will ensure that the turnaround time in setting up the same is minimum – as the support groups are trained to understand the agility required in these kind of work
· Where there is a skill gap in the kind of work that is required to be executed, an internal or external training will be arranged to overcome the gaps
· Organization continuously provides access to new tools, technologies that the projects can get benefited.

For more information check the following resources
Offshore Software Development Services
Software Development Blogs

Prototyping in Software Development

noreply@blogger.com (Ravisat) — Wed, 26 Mar 2008 15:06:00 +0000

This article addresses the needs of prototyping in Software Development

1. Why Prototype?
Prototyping is a means of exploring ideas before you invest in them. The best reason to prototype is to save time and resources. So, for a minimal investment, you can find usability and design problems and adjust your UI before you invest heavily in the final design and technologies.

On examining the needs of your particular project, you might come up with reasons for creating a prototype other than saving money. Is the goal to explore a new interface model? Make modifications to one part of the existing design? Investigate a new technology? It’s important to be clear about why you’re building what you’re building before you start. If you begin with clear goals, you can be direct and effective in your efforts. The reasons for creating prototypes fall into three basic categories:

1.1 Proof of concept.
Among some teams there are disagreements about the future direction of a project. You can use a prototype to prove that an idea or new approach has merit or value. A prototype can help illustrate that an idea works, express its qualities in a visual and interactive way, and/or motivate team members to think about the problem from another perspective.

1.2 Design exploration.
If you design interactive things, the only way to explore how something will be used is to create a mock-up and interact with it. Sometimes the mock-up is tied to a usability study, where parts of the prototype can be evaluated in a structured way. Sometimes it’s just a way to clearly express to a developer how something should work or look. In many cases, a designer might simply be experimenting, in an effort to get a sense for what approach might work. Anyone on the team can use prototypes to explore design issues, although designers are generally the most skilled. Design explorations should be directed at trying to solve specific problems that you’ve recognized in your product.

1.3 Technical exploration.
Developers investigating implementation approaches to a problem often try out different coding techniques to see if they work well. Using HTML, Jscript, SQL, DHTML, Win32, or specific coding approaches within each technology have different tradeoffs. Sometimes a prototype represents an exploration into what technology will work well to support a certain UI or web feature.

Sometimes prototypes are created for a combination of these reasons. If a team plans well enough, they can allot time for a developer and a designer or project manager to work together on a prototype. In such cases, it’s extremely important to clearly define the goals and the contributions each team member is expected to make. You want everyone to be clear on what the goals are, what’s at stake, and what the potential outcome will be.

2. Who is Involved?
Prototyping can be done informally by anyone, regardless of their background or role in the project. It’s easy to make a simple but effective prototype by taking a bitmap from Adobe Photoshop, putting it into the Microsoft FrontPage Web site creation and management tool, and adding active buttons or links. These lightweight prototypes only go so far, and can become unwieldy for complex interactions.

For more formal prototypes by larger teams, a developer or project manager will often collaborate with a designer and a usability engineer. Together they’ll generate ideas, build a prototype that represents the best ideas, and then go into the lab to see how effective it is in solving user problems. Developers might get involved if they can spare the time, or if their technical expertise is needed. Often the designer or project manager will do most of the scripting or coding to build the prototype.

I will follow up with more information about prototyping in my subsequent blogs. These will be part of my Usability Engineering Service offering by Silicus in Software Development

For more information post a comment or send a mail to Ravi@silicus.com

Usability Engineering in Software Development

noreply@blogger.com (Ravisat) — Sun, 23 Mar 2008 05:51:00 +0000

Need and importance of Usability Engineering in Software Development

Nowadays usability of interactive systems is considered a fundamental quality attribute. The human computer interaction discipline provides requirements and needs about the factors to take into account and methodologies to develop user friendly and interactive applications.

Due to the growing importance of human computer interaction and the agility of software development life cycle it is very important to involve end users and present them a picture of what they can expect and how the usability of the system is being designed. To achieve this Silicus Technologies has established usability engineering as a service offering for its customers.

Inclination towards adapting agile methodologies (Example: SCRUM) is growing in Software Development and thus is making more sense to involve the stakeholders during UI Design phase and release the products/prototypes in shorter cycles and incorporate the feedback into the next iteration or Sprint – important features of agile development.

Silicus usability engineering services provide a structured user centric approach to link the life cycle activities with usability perspective. The focus of this service offering is to make sure that the development team members always know which activity is being developed and what the related activities are in terms of end user interaction. This is an agile, iterative based approach with the required evaluation after each cycle, Sprint.

Silicus has the expertise and infrastructure for successful execution and delivery of usability engineering in the following areas.

· Extensive experience in onshore usability – Eliciting User Interfacing needs and getting prototypes done from the offshore teams with a faster turnaround time
· Experience of prototyping solutions in diverse domains, industries and technologies
· Experience in UI Technologies that help in prototyping: HTML, XML, Java, .Net, VB, ASP/PHP etc.
· Extensive experience in prototyping using Dream weaver, HTML, CSS, Scripting and Flash.
· Extensive experience in Third party tools like Infragistics, Joomla, Component One etc

Post Comments to get more information on this or contact Ravi@silicus.com

Technical Documentation in Software Development

noreply@blogger.com (Ravisat) — Sun, 23 Mar 2008 05:39:00 +0000

Technical Writing in Software Development

One of the main challenges in Software development life cycle is to address the requirements and needs of writing effective technical documentation so that others can use it to develop and maintain a system. This also involves having experienced and trained writers in the organization to produce documentation of high quality and usefulness that is in line with the accepted conventions and standards.

An Organizations Software Development Services preferably should include Documentation as one of the service offerings and must be planned as an important activity during the project planning phase of the Software Development Life Cycle. Keeping in this mind Silicus Technologies has established and matured its documentation services for Software Products.

Silicus Documentation services is based on an approach that allows software teams to produce only the documentation that has a demonstrated community of consumers (end users) that will serve the project throughout its entire life cycle.

Silicus offerings in this area include identifying experienced technical writers as part of the product teams who are capable of producing documents that are clear, pertinent to its intended use and consistent. This will help the stakeholders to realize maximum benefit by understanding the strengths and shortcomings of the different product elements and be in a position to enhance the product for the future roadmaps.

Silicus has a team of documentation specialists who can provide the following technical writing and online documentation preparation services

· Documenting software interfaces
· Documenting use cases
· Documenting functional scenarios
· Documenting Software specifications
· Installation Manuals
· Maintenance Manuals
· User Manuals
· Quick Reference Guides
· Online Help
· Release Notes

For more information send a comment to Ravi@silicus.com

Process Tailoring in Software Development

noreply@blogger.com (Ravisat) — Wed, 19 Mar 2008 17:13:00 +0000

Best Practices and Guidelines for Process Tailoring in Offshore Software Development

What is Tailoring in Software Development?
Tailoring in Software development is the process of extracting a set of processes, tasks and artifacts from the organizations established processes, tasks and artifacts so as to best suit a project to achieve its objectives.

Practices and Guidelines

It is very important that we have a set of tailoring guidelines that will guide the development teams to let them decide what is best for the projects. The guidelines must also specify is that what is Tailorable and what is mandatory. For example in a software development project if a project manager says that the project need not maintain a project management plan then it should be not acceptable as per the tailoring guidelines. So basically there will be some processes, tasks and artifacts that will have to be developed and maintained in a software product development project.

So these guidelines must take into account multiple aspects before being released as part of the organization quality management system. These aspects must look into the current state of process implementation, customer’s needs and objectives, project characteristics etc.

Organizations that are offerings services for different types of projects like Full life cycle development, maintenance, QA, Technical support must also look into coming up with life cycle models for each of these type of software projects. These life cycle models must go hand in hand with the Process tailoring guidelines established at the organization level.

The following steps can be considered as some important points that can help in coming up with the tailoring tasks at the project level.

STEPS AT PROJECT LEVEL
Identify Project Characteristics
Identify the characteristics of your software project. These characteristics will be useful in formulating a project strategy and in tailoring processes.

Formulate a Project Strategy
Based on the characteristics of your project, formulate a strategy by referring to Process tailoring guidelines that are established at the organization level.

Select a suitable Quality Management System (QMS) process
In QMS, processes must be defined for the different types of projects; example
· Development (Agile, Maintenance, Waterfall etc.)
· Maintenance projects
· QA Projects
· Technical Support Projects

The tailoring guidelines for project management and configuration management must be made applicable to all projects.

Select lifecycle model for the Software development project and tailor process element accordingly. For each process element, you can decide to do one of the following:

· Implement the process element as per guidelines
· Waive the process element
· Replace the process element
· Add a new process element

Waivers and replacements from the tailoring guidelines and new process elements not defined in the tailoring guidelines should be highlighted in Project Management Plan as Deviations and appropriate process must be followed in getting approvals for the waivers and deviations.

In my next blog I will highlight the use of collaboration tools like Project Server and SharePoint and demonstrate how we can use simple features to come up with an effective way of performing process tailoring for software development projects. This will also address the fulfilling of GP 3.1 in CMMi Ver. 1.2 – Establishing projects defined process. We will understand more about Projects Defined process.

For more information check the following resources

Offshore Software Development Services

Software Development Blogs

Project Planning Stakeholder Involvement

noreply@blogger.com (Ravisat) — Sat, 15 Mar 2008 05:33:00 +0000

Stakeholder Involvement in Project Planning
Here is a sample in which we can plan stakeholder involvement in project planning during software product development process. The roles that are described are based on Microsoft Solution Frameworks (MSF) model and the Project Planning activities are taken from Capability Maturity Model Integrated (CMMi) 1.2 version Project Planning Process Areas Specific Practices.

Any software product development project that is managed needs to define the relevant internal and external stakeholders and the type of involvement depends on the role they are performing in the project. We can use a typical stakeholder involvement plan to plan for the activities of stakeholders involvement and the frequency and kind of involvement that is expected.

We can use Microsoft Sharepoint Server 2007 to create a custom list that can track the involvement of these stakeholders as planned during the project planning phase of any software product development process. This list can be created as part of your project portal that gets created if you are using Microsoft Project Server 2007 as your enterprise project management tool for your software product development process.

Once exposed this list that has the involvement can be tracked and may be exposed to your customers (as an extranet value add) so that if there are tasks that dependent on customer then it becomes easier to track these tasks to closure - i.e., if the customer is identified as a relevant stakeholder.

In addition to the tools such as Microsoft Project Server and Microsoft Sharepoint Server 2007 if you are using Team Foundation Server (TFS) (Visual Studio Team System Solution) as your software product development management tool then TFS provides work items (you can customize as per your project needs) and these tasks that are derived out of stakeholder involvment planning can be tracked via TFS.

The attached document can help you as a guideline to plan for internal and external stakeholders in your Software product development process. The involvement parameters are based on standard RACI terminology.

Click the link to get the guideline for planning stakeholder involvement in project planning during your software product development processes
Project Planning Stakeholder Involvement

This blog will be posting similar guidelines, best practices and processes for planning stakeholders involvement for other process areas including the different phases of Software Product Development Life Cycle (SDLC). And I will try to address the use of Microsoft SharePoint Server in identifying and involving Stakeholder during your software product development.

For More info and for Similar guidelines send a mail to Ravi@silicus.com

Best Practices Framework

noreply@blogger.com (Ravisat) — Mon, 10 Mar 2008 15:29:00 +0000

Outsourced Software Product Development Best Practices Framework

Silicus has implemented Software Product Development best processes and practices framework that is based on sound Quality principles and years of experience in developing software products. Silicus understands the importance of process frameworks in software product development projects and has adopted different aspects of the Microsoft Solutions Framework (MSF) in order to successfully manage the Software Product Life Cycle.

Microsoft Solutions Framework (MSF) is a highly customizable, scalable, fully integrated set of software development processes, principles, and proven practices designed to deliver the type of guidance desired by the user when and where it is needed. Silicus implementation of MSF provides the foundation for planning, building, and managing technology projects that help organizations to frame problems and facilitate effective creation and use of technology to solve business problems.

Silicus’ MSF Process Model recognizes that there are certain milestones that are essential to project success, and different stake holders must be capable of supporting their achievement. Silicus' own project methodology is based on this Process Model and its internal Groups will adhere strictly to this process for each and every product deployment to ensure success. Silicus’ MSF Process Model is milestone-based and provides guidelines on planning and controlling projects based on their scope, the resources available, and the schedule. The model defines critical milestones for development, creates accountability, identifies risks and mitigation strategies, and defines the variables and priorities that affect scheduling, feature, and trade-off decisions.

Silicus Process Model based on MSF provides a seamless experience with Visual Studio 2005 Team System for process automation and guidance within the software development life cycle (SDLC). Silicus Process framework uses two MSF methodology templates across its different software product development projects.

MSF for Agile Software Development
MSF for CMMI® Process Improvement

Alignment with Customers

noreply@blogger.com (Ravisat) — Fri, 07 Mar 2008 14:42:00 +0000

Alignment with customers - Importance during outsourced software product development process

The value provided by a vendor to its clients does not stem from its offerings, or from the communication and network infrastructure that supports interactions with customers, and not even from the professional skill network of the vendor including its management, employees, partners and consultants.

Value lies in the cumulative co-creation experience of individuals belonging to the customer organization, during interactions with the provider’s network at a specific point in time, in a specific location, in the context of a specific event.

Read More

Rescuing Flaming Projects

noreply@blogger.com (Ravisat) — Thu, 06 Mar 2008 11:06:00 +0000

Rescuing Flaming Projects

The software industry is a glowing world of flaming projects that are in destructive dives. Every aspect of the industry- developing, migrating, maintaining, or implementing software packages- has its unfair share of flaming projects that often can destroy if not severely damage companies’ profitability.

Process Excellence

noreply@blogger.com (Ravisat) — Tue, 04 Mar 2008 13:31:00 +0000

Process Excellence @ Silicus
Silicus implements and improves its Quality Management System (QMS) by having a road map for Process improvement. We adopt a high-level methodical approach to explore process improvement areas and thereby implementing a suitable solution to achieve process improvements across organization that are executing software product development projects.

Through our affinity towards continuous improvement and learning during the software development process we have built a reputation for on-time, on-budget, high quality implementations that have exceeded our customers' expectations.

SEPG
In Silicus, the Quality Practice has an internal support group known as Software Engineering Process Group (SEPG) – and establishing this group has been the first step to ensure a process-centric approach within the organization. The processes are implemented and the feedback from the implementation is collected and analyzed to ensure a continuous improvement in the established processes. Implementation of various industry standard quality models like ISO, CMMI among others have contributed to the process improvement initiatives to higher maturity levels.

In Silicus, the Quality Practice has an internal support group known as Quality Assurance Group (QA) which takes care of implementing the Quality Management System (QMS) activities in the projects. Under the guidance of SEPG, Quality Analysts (QAs) are deputed to each project and they work with the project team members to facilitate the implementation and adherence of the Quality Management System (QMS).

Silicus importance to Quality is driven by the top management which helps in enhancing our competencies and delivering business value to customers. All our groups have been audited for their process maturity under the various globally accepted quality models and standards.

Other than ensuring the process adherence by all the groups in the Organization, SEPG group is also responsible for maintaining the Quality Management System. Quality initiatives by SEPG like ISO, CMMI, Information Security and Business Continuity strengthen Silicus’ commitment to customer satisfaction and delivery excellence.

For more information on Silicus Process excellence in Software Product Development and Maintenance projects OR Software Product Development Processes and Practices submit a comment with your details or send a mail to Ravi@silicus.com

Silicus Quality Processes

noreply@blogger.com (Ravisat) — Tue, 04 Mar 2008 13:14:00 +0000

Overview of Silicus Processes

A well established process is the foundation for higher business value, more satisfied customers, and better products. Silicus Quality processes are driven by the fact that Process implementation and adherence, implemented in a right way, minimizes overhead while delivering significant benefits to development teams, management and the customers.

Silicus Value
Silicus projects follow a process centric approach enabling deliverables to meet expectations according to the unique needs of its customers.

Silicus processes help in creation of maximum alignment between development expertise and business expectations by:

Driving process implementation across teams

Facilitating communication and collaboration between development teams, management and customers

Encouraging continuous improvement and innovation in process maturity.

Focus and Commitment
Silicus commitment to Quality and Processes focuses on optimizing the process, people and technology skills to answer the core challenges of software development. Our goal is to deliver solutions to customers that positively impact their return on investment. Silicus focuses on following processes that have a larger impact on the organizations value proposition and customer business goals. This commitment towards quality and processes is a collaborative engagement model that ensures close alignment between Organization objectives, Business strategy, Process improvement and Value creation.

Innovation
Our success is based not only on the quality of our deliverables and customer feedbacks but also on the sustainability of innovations in our established processes. We constantly focus our process innovation to work on industry best practices for achieving positive business results. These innovations let different teams help develop new ways of working and thinking that eventually translate into achieving the stated objectives of the project. Process innovation at Silicus is continuous and is driven towards implementing initiatives that are based on a thorough understanding of the current strengths and weaknesses of the organization's processes and process assets.

In order to achieve the organizational objectives Software Engineering Process Group (SEPG) at Silicus drives towards innovations with the following tasks

Periodic appraisal of project-level processes and capabilities
Appraisal of organizational capabilities
Identification of improvement opportunities
Developments of plans to define, implement, and deploy innovative and improved capabilities.

Benefits
We work with software companies across the globe and do understand our customers’ issues, priorities and constraints. Silicus Quality Process facilitates the project teams to work collaboratively with the customers and to respond to their problems.

All groups in Silicus follow the established process thus providing benefits to different stakeholders.

Customers experience the benefit in their projects by having the visibility at any point and ease of governance of the project

Project sponsors experience the benefit by having the ability to better manage project scope, costs and risks

Development teams experience the benefit by growing leadership capabilities to improve overall organizational effectiveness

Management experience the benefit by strengthening capabilities, identifying and implementing process improvement opportunities, realigning focus for better return on investment.

All of these help achieve the basic quality goals such as on time delivery, within budget and high quality deliverables.

eCommerce and CRM

noreply@blogger.com (Ravisat) — Thu, 28 Feb 2008 05:48:00 +0000

Silicus’ E-commerce and CRM CoE is focused on user-centric, mission-critical business software for interaction with customers and partners to enable enterprises in automating processes, making more profitable decisions and accelerating growth. Silicus has vast experience in developing E-Commerce and CRM platforms for various industries including:

High Tech
Commercial Printing
Financial Services
Independent Distribution
Health & Fitness
Construction

With experience ranging from consulting, process re-engineering, customization & development of Off-the-Shelf products and developing industry specific software products, Silicus has vast experience to offer through the E-Commerce and CRM CoE.

Silicus expertise in E-Commerce and CRM includes:
Applications
Content Management
Commercial Printing
Configuration and Pricing Management
Online Campaign and Promotions Management
Shopping Carts
Online Transactions
Order Management
Personalization
Marketing Automation
Sales Force Automation
Mobile Sales Force Automation
Customer Order Management
Call Center & Service Management
Business Analytics
Partner Relationship Management
Central Dashboards for management and users
Account Profile management, including products, projects, purchase histories and service agreements related to an account
Sales opportunity management, including sales discovery, sales timeline management and team selling
Calendar/Activity management
Messaging and notifications
Tools for data import, mail merge and list management
Messaging and notifications

Verticals
Commercial Printing
High Tech Software
Retail and Distribution
Transportation and Logistics

For more Information: Ravi@silicus.com
http://www.silicus.com/

Refer to the Case Study:
http://download.microsoft.com/documents/customerevidence/25028_Nationwide_Graphic.doc

Enterprise Project Management

noreply@blogger.com (Ravisat) — Thu, 21 Feb 2008 11:56:00 +0000

Enterprise project management @ Silicus Technologies using SharePoint 2007, Project Server 2007, Team Foundation Server 2008, Visual Studio 2008.
All Silicus engagements are incubated by professionals from our Centers of Excellence with know-how on tools, processes and best practices developed through research as well as by harvesting non-IP specific practices across engagements. Additionally teams are trained to use our proprietary collaboration tools for distributed product development to enable performance monitoring and providing real time dashboards. Through these tools we accelerate knowledge transfer and knowledge capture, as well as leverage them for daily interactions and transparency.

Some of the tools that we use for Microsoft Competency Center are:

Team Foundation Server 2005 (TeamPlus – Silicus Solution for effective development management)
· Software Development Management Tool
· Manage Work Items (Issues, Bugs, Change Requests, Requirements etc)
· Testing, Bug Tracking, reporting, analyzing
· Requirement traceability, change management
· Source Control Management
· Process and work item customizations Development
· Visual Studio 6.0, 2003, 2005
· Visual Studio 2008 (under evaluation) Source Control Management
· VSS – for in house VSS hosting
· Source Offsite – for remote VSS access
· CVS

Project Management and Collaboration Tools (All Platforms) Share Point 2007 (Spandan – Silicus intranet solution)
· Document Repository
· Knowledge Management
· Intranet for help desks (IT Requests etc)

Project Server 2007 (MCube – Silicus solution for effective project management)
· Timesheet management
· Task Management
· Project Schedule Management
· Project Effort monitoring
· Resource Management
· Risks and Issue Management
· Project Monitoring and Control
· Project Document Managements (with configuration and Baselining features)

Communication Tools
· Email based
· Net Meeting
· Live Meeting
· Chat
· Video and Audio Conferencing

In addition to the above we use Microsoft Office tools, Visio, Project Professional for day to day activities – we are a Microsoft Gold Certified partner company and have access to all the latest tools and technologies from Microsoft.

Methodology:
· Traditional methodologies like Waterfall and Iterative development methodologies
· Agile methodologies like MSF – Agile (Microsoft Solutions Framework), SCRUM based models
· All our development and maintenance projects do follow the ISO 9001 and CMMi Level 3 requirements and will be audited internally and externally for process adherence

Contact Ravi@silicus.com for more information
http://www.silicus.com/

Software Technology Trends

noreply@blogger.com (Ravisat) — Wed, 20 Feb 2008 09:58:00 +0000

Software Technology Trends - Silicus Value Proposition
Silicus is a partner to several software development organizations. We make every effort to keep abreast with latest market trends, build capabilities around them and incorporate in customer engagements. We share the same desire as our customers to create differentiation in how we bring new products to the market. We enable the success of our customers through technology and business model innovation. While our peers observe and talk about the paradigm of Enterprise 2.0 we deliver it through our Global Sourcing Framework and Strategic Alliances.

While most are debating over semantics we look at the transformation in the software development ecosystem comprising of Technologies, Business Models and Software Delivery Models.

While we assist our customers in adopting trends in software delivery models leveraging the latest in technology offering from platform providers, it is our Business Models that effectively make us an R&D Outsourcing Provider leveraging our Global Sourcing Framework (Vendor Model) and Strategic Alliances (Partner Model). Some of the predominant trends in the transition of software development and delivery are:

1. Web 2.0
2. SaaS, and
3. Service Oriented Architectures (SOA)

For more Details Contact Ravi@silicus.com
http://www.silicus.com/

Software Quality Engineering

noreply@blogger.com (Ravisat) — Fri, 15 Feb 2008 15:00:00 +0000

Silicus has expertise in Manual and Automated Testing including performance-related testing services such as performance analysis, benchmarking, load / stress testing and performance tuning. Our Software Engineering Process Group has helped in developing a wide range of tools for synthetic load generation, performance monitoring and automatic report generation.

Silicus' Quality Assurance offerings include:

Functionality and UI testing
Web testing
Compatibility testing
Internationalization (i18n) and Localization (l10n) testing
Performance testing
Server testing (database, directory and Internet)
Load / stress testing
Manual testing
Test Automation
Test design and scripts
Regression testing
Test strategy preparation
Compliance testing
Test plan documentation
Compiler testing
Test script documentation
White box testing
Design review
Black box testing
Acceptance testing

Our capabilities include expertise in using the following tools:

Microsoft Team Foundation Server - Test Manager, Code Coverage, Unit Testing and Web Testing
IBM Rational Test Studio - Quantify, Pure Coverage, Robot, TestFactory and Purify
Rational Robot, Segue SilkTest and Mercury WinRunner for test automation
TestManager and TestDirector for test management
ClearCase, CVS and VSS for configuration management
ClearQuest, Bugzilla and PVCS for defect management

Tool and Automation Services

Functional and UI Testing

Software Compatibility Services

Security Testing Services

Performance Testing Services

Web Testing Services

Application Testing Services

Mobile Testing Services

Testing Outsourcing Solutions

Quality Management System

Software Engineering

noreply@blogger.com (Ravisat) — Fri, 15 Feb 2008 14:56:00 +0000

Silicus Engineering Expertise includes:

New product concepts, robust technology platforms, innovative software delivery models, new versions and differentiating features – built to compete. Silicus Product development engineering services deliver high fidelity products while ensuring low and predictable development costs.

New Product Development
Technologies (.NET, Open Source, Java/J2EE), Platforms(Windows, HP-UX, Solaris, AIX, Linux), Competencies(Storage Technologies, Security and Compliance, E-Commerce and CRM, Enterprise Systems Management )

Usability Engineering
Eliciting needs and getting prototypes done from the offshore teams with a faster turnaround time, prototyping solutions in diverse domains, industries and technologies, UI Technologies that help in prototyping: HTML, XML, Java, .Net, VB, ASP/PHP etc , prototyping using Dream weaver, HTML, CSS, Scripting and Flash, Third party tools like Infragistics, Component One etc.

Porting
Porting to additional technology platforms, Support multiple user interfaces, Modernize architecture from 2-tier to n-tier, Transition products to a hosted services model, enabling Software as a Service (SAAS), Re-architect the product to support multiple versions to meet the needs of a range of clients from enterprise to SME customers, Support multiple alternatives for architecture components e.g.: Crystal Reports and Microsoft SQL Server Reporting Services, Internationalize and localize the product into multiple languages

Documentation
Product and Technical Documents, Documentation Support, Training and Educating Material, FAQs, Customer Help, Editing and Indexing, Content Publishing, User Guides, Data Sheets

Contact Ravi@silicus.com for more details
http://www.silicus.com/