Ensuring that builds are posted in the locations where people are located

In today's world, applications are developed all over the world, in the sense that if you look at a product development team, it will have members located all over the world. So, I have worked on several products where some developers are based in a location in India, some are based in Germany, and some others are based in multiple locations in the United States. Now, one can argue that this would be confusing and not an ideal state, but the fact remains that because of reasons related to costs, acquisition of companies (I once had a colleague who was absorbed into the company as part of one product, and then assigned to another product based on a resourcing decision - with the associated issue being that the original product was being developed out of his location, but for the new product where he was now associated, he was now a remote worker), and the need to meet the geographic needs of talented people who would otherwise not join, teams can get geographically dispersed. So, let us take it for granted that such teams exist, and consider some of the problems that can happen with such teams. We will talk about coordination & communication issues in a separate topic, but one major issue with teams working on large products is the sheer size of getting the builds to them on a regular basis. Consider teams that work on applications such as MS Office, Photoshop, CorelDraw, and many other such products, the sheer size of the application builds can be upwards of 1GB+.
When you are working on an application development program, it is important to work on the newest version of the application. Typically for most product development applications, this means that a new build will be generated every day, available for the developers and testers. This allows the testers to test with all the fixes that have been made the previous days, and also ensures that developers have the same confidence that their fixes are in, and are being tested regularly. Now this sounds fine when everybody is located in the same geographic location (I mean there are other issues related to ensuring that the build is a solid build, that build failures are detected early, and so on), but gets more challenging when members of the development team are located in different locations. Given the size of some applications (as I mentioned above, they can be 1GB or more sometimes), even with very fast connections, it can take time to ensure that these builds are delivered to the remote locations within a short period that they are available in the location where they are generated. And when you consider locations such as those in India, the availability of fast broadband lines is not of the same assumed speed as those available in the United States (or which can actually be more expensive). So, there needs to be a lot of thought given to how these builds will reach the different geographic locations. All this rules out the possibility of transferring builds manually to the different geographic locations; instead what needs to be done is to add a sequence of commands in the build script near the end that check for whether the build has been made, that the sequence has not showed any obvious errors (and if possible, incorporate some smoke tests to ensure that the build launches and works fine) and then does an automatic ftp transfer to default directories on the other geographic locations. The reason for incorporating smoke tests is to ensure that you do not start sending out builds to the other locations that are not possible to use. Even in such cases, you will find that once in a while, there will be failures and build will not be available, but in most cases, you will find that you needs will be met.
However, there is a complication that can happen about setting the timing of the build delivery across multiple locations, and I will cover that in a forthcoming article (link to next article - TBD).

What are concepts of Requirements Engineering? Different tasks of requirement engineering - Inception and Elicitation.

Requirement Engineering encompasses a set of tasks that lead to an understanding of what the business impact of the software will be, what the customer wants, and how end-user will interact with the software. The basic agreement between end-users and developers on what the software should do is given by requirement engineering.

It gives stakeholders anopportunity to define their requirements understandable to the development team. Designing and building an elegant computer program that solves the wrong problem is a waste. This is the reason why it is important to understand what customer wants before one begins to design and build a computer-based system. Requirements Engineering builds a bridge to design and construction.

There are seven distinct tasks to requirements engineering namely inception, elicitation, elaboration, negotiation, specification, validation and management.

INCEPTION

At inception, the problem scope and its nature is defined.
To initiate requirement engineering, steps include:
- identify stakeholders.
- recognize multiple viewpoints.
- work towards collaboration.
- ask the first question.
The main output or work product of inception task is a one or two pages of
product request which is a paragraph summary of the problem and its nature.

Elicitation

Elicitation is a task that helps the customer define what is required. The problems encountered are problems of scope, problems of understanding, problems of volatility. Elicitation makes use of a requirements elicitation format that combines the elements of problem solving, elaboration, negotiation, and specification.
Joint Application Development is one collaborative requirement gathering technique that is popularly used to elicit requirements.
The tasks involved in elicitation can be categorized into three groups, namely, pre-joint meeting tasks, joint meeting tasks and post-joint meeting tasks.

Quality Function Deployment is a technique that emphasizes an understanding of what is valuable to the customer. It identifies three types of requirements normal requirements, expected requirements and exciting requirements.

The output of the elicitation task can vary depending on size of thesystem or product to be built. For most systems, the output or work products include a statement of need and feasibility, a bounded statement of scope for the system or product, a list of customer, users, and other stakeholders who participated in requirements elicitation, a description of the system's technical environment and a priority list of requirements, preferably, in terms of functions, objects and domain constraints that apply to each.

Software Development Methodology - Joint Application Development (JAD)

- Joint Application Development(JAD)is a process that is originally used to develop computer based systems.
- Joint Application Development is a process that accelerates the design of information technology solutions.
- JAD uses customer involvement and group dynamics to accurately depict the user's view of the business need and to jointly develop a solution.
- JAD is thought to lead to shorter development times and greater client satisfaction because the client is involved throughout the development process.
- JAD centers around a workshop session that is structured and focused. Participants of these sessions would typically include a facilitator, end users, developers, observers, mediators and experts.
- In order to get agreement on the goals and scope of the project, a series of structured interviews are held.
- The sessions are very focused, conducted in a dedicated environment, quickly drive major requirements.

Concept of Joint Application Development

- User who do the job have the best understanding of that job.
- The developers have the best understanding of the technology.
- The software development process and business process work in the same way.
- When all groups work equal and as one team with a single goal, the best software comes out.

Principles of JAD Process

- Define session objectives.
- Prepare for the session.
- Conduct the JAD session.
- Procedure the documents.
JAD improves the final quality of the product by keeping the focus on the upfront of the development cycle thus reducing the errors that are likely to cause huge expenses.

Advantages of Joint Application Development

- JAD decreases time and costs associated with requirements elicitation process.
- The experts get a chance to share their views, understand views of others, and develop the sense of project ownership.
- The techniques of JAD implementation are well known as it is the first accelerated design technique.
- Easy integration of CASE tools into JAD workshops improves session productivity and provides systems analysts with discussed and ready to use models.
- Enhances quality.
- Creates a design from the customer's perspective.