What is an Agile Process Improvement?

A process improvement program is successful only when the meaning of the word ‘process’ is clearly understood. Process means work. So when one improves, the other one also improves. The quality of the software depends a lot on the process. Whenever a change is introduced, a temporary drop in performance is always recorded. In most cases what happens is that the organization stops the implementation of changes fearing the disruption in the normal work since so much effort is required. To avoid such situations, the changes need to be adaptive. It is the agile process improvement that makes this possible. You might say that such a way of iterative improvement is not new. Well, the agile techniques introduce discipline in the whole program.

Stages of Agile Process Improvement

The following are the stages of the agile process improvement:

1. Initiating:

Ø  Stimulus of change

Ø  Set context

Ø  Build sponsorship

Ø  Charter infrastructure

2. Diagnosing:

Ø  Characterize current and desired states

Ø  Develop recommendation

3. Establishing:

Ø  Set priorities

Ø  Develop approach

Ø  Plan actions

4. Action:

Ø  Create solution

Ø  Test solution

Ø  Refine the solution

Ø  Implement solution

5. Learning:

Ø  Analyze

Ø  Validate

Ø  Propose future actions

- The improvement cycles are meant to be followed systematically so that the results might be obtained in time ranging from 2- 6 weeks.

- The whole process lets you maintain a balance the workload as well as the improvement. 

- The flow of the process is as follows:

1. Prioritized list of improvements
2. Detailed plan for the current cycle
3. Implemented improvement
4. Feedback

- After this process, the following becomes possible for the organization:

1. Identification and resolving of the issues earlier in the cycle.
2. Learning process regarding how to tackle difficulties and working of this process.
3. Adaption to the business needs that keep changing.
4. Giving response to the feedback.

- The sponsor holds the responsibility for prioritizing the improvement backlog at the start of each sprint. 

- Also, he is the one responsible for ROI. 

- Prioritization is a good tool for the sponsor to direct the change. 

- Using prioritization, the goals and feedback can be revised from quality assurance. 

- A focus can be kept on the benefit received from each improvement cycle. 

- PPQA deploys and evaluates the improvement in organization in every sprint. - The improvement package consists of 4 sprints namely:

1. Prototyping
2. Piloting
3. Deploying
4. Evaluating

- Active participation and leadership is required for a change to take place. 

- An endorsed vision and status quo is required for the beginning of the process. 

- Both of these are established via SCAMPI and CMMI. 

- The change is led by the management on an everyday basis.

- An excellent description is provided by the generic practices of CMMI for the leadership purpose.

- Similarly participation is a key element that is facilitated by the change team. - A vision is required for initiating the improvement project. 

- The initial improvement backlog is defined by 3 things namely scrumMaster, change team and the work owner i.e., the sponsor all based up on an assessment. 

- The organization is facilitated by the change team.

- With each sprint a tangible improvement is delivered. 

- The change is led by the management in a sprint.

- The effect introduced by the change is evaluated at the end of each sprint by PPQA. 

-The new improvements are defined by the work-owner who is also responsible for adding those in to the backlog of improvements and prioritizes it.

-Commitment is supported at the end of the sprint by appraisal.

-The improvements can also be continuously integrated in to the organization’s way of working. 

What are the differences between waterfall, spiral, iterative and scrum processes?

The waterfall, spiral, iterative and scrum are all agile software development models! At a glimpse of them, they may all seem like similar software development processes. But this is absolutely wrong! At surface they may appear to be one and the same but when you go in to the depths of the understanding of these processes you will come to know that there is a “considerable” difference among them. 

In this article we are going to discuss among all these processes. Let us go through these processes one by one:

1. Waterfall Model: 

- Waterfall model follows a sequential design rather then following a haphazard order of processes. - By the name itself you can make out the flow of the development is downwards like a water falling down an actual waterfall. 

- Most of the agile software development models have same number and types of phases, but the way they are implemented is different.

- The waterfall model can only be implemented in the software projects that require highly structured development environments. 

- This is the only agile development process that can be adapted for both the hardware and software projects. 

- If you have implemented waterfall model for the development project you cannot move on to the next phase before completing the previous one.

- However, in some very extreme cases, the developers hold the privilege to modify it to suit their needs. 

- The water fall model is based up on the philosophy that if you spend more time in the early phases looking for the errors and faults, the less time and effort will be spent in the later stages which are quite complex too.

2. Spiral Model:

- This software development model is a resultant of the combination of prototyping in stages and designing and thus possesses the combined advantages of both the top down and bottom up concepts. 

- Unlike the other software development processes, the spiral model is intended for use in the projects that are quite large, expensive and complicated. 

- Prototyping is nothing here but the iterative development combined with the controlled aspects of the waterfall model.

- It does allow for the incremental releases of the software at the end of every refinement. 

- Unlike the waterfall model, the spiral model is inclusive of the risk management for the identification of the major risks whether managerial and technical and determines how to lessen it. 

- This model evolves around the idea of the continuous refinement of the requirements definition, requirements analysis, implementation and software design and so on. 

- This model makes use of the same stages as the waterfall model but they are separated by risk assessment, planning and building of prototypes and simulation. 

- Documentation is produced whenever needed and not unnecessarily.

3. Iterative and Incremental Development: 

- This software development model was developed as a means to overcome the minus points of the waterfall model. 

- Unlike the other software development processes, this one starts with a lot of initial planning and continues with many cyclic interactions and finally ends with deployment.

- This software development model in turn forms a very important part of many other agile software development process like RUP and extreme programming. 

- The iterative and incremental development model is known to follow plan- do- check- act cycles of the business process improvement.

4. Scrum: 

- Scrum is so contrasting with all the other software development processes. 

- The waterfall model is intended to complete the project in one discipline one step at a time and goes for the next discipline in next step. 

- It delivers the business value at the end itself but this is not the case with the scrum!

- Here with every iteration a business value is delivered.

What are different characteristics of alpha testing?

For alpha testing, it won’t be wrong if we say that it is another name for acceptance testing. Alpha testing is very much similar to the acceptance testing. Alpha testing is performed in the front of the customer or the client for their satisfaction and acceptance.

The client or the customer needs to verify or check whether the software artifact has been developed according to their:
- Service level agreement or SLA as it is abbreviated.
- Requirements
- Specifications
- Defect rate efficiency or DRE as it is known in short form.

If during the alpha testing the client or the manufacturer missed something, and discovers it later, then the software system has to again undergo a second alpha testing before giving the software product another green signal. But, client or customer revision is required mostly in beta testing.

Alpha testing can be formally defined as an actual operation or simulation testing before the launch of the software system and it does not involves software developers.

It is the testing of software on the site of the software developer by the customer or the client after the completion and finishing of the software system or the application.

- Alpha testing can also be called a kind of user acceptance testing or UAT a sit is known in short form.
- Alpha testing is carried out at the site of the software development. It is done by the clients or the customers. When the project is the development phase, it is said to be under alpha testing.
- Alpha testing allows the software tester to make some minor changes or modifications during the testing or at the end of it.
- It is carried out in the front of the developers, so that they can now what is the error or the bug and what it is and how it can be fixed efficiently.

- Alpha testing can be thought of as a stage of software prototype at which it may be discovered that the software system does not have all the required functionalities and specifications. But, one thing is definitely sure that the software system will have all the core functionalities and operational abilities and it will efficiently accept the input data values and generate the proper output as expected.
- Alpha testing is carried out on any system other than the system on which the software system was developed in the office of the developer.
- Client or the customer carries out the alpha testing under the leadership of the software developer.
- These days the alpha testing is being done by both the end users and the software developers.
- Alpha testing is the complete testing as it contains most of the functionality and specifications.
- Sometimes a group of clients or users are selected to perform alpha testing for the software system.
- Mostly the alpha testing is performed in-house or sometimes is performed by an external testing firm which in close terms or cooperation with the concerned software development corporation or the company.
- Sometimes it may also happen that the software developers may test the software system in front of the end users present within the development environment.
- This kind of testing is popularly known as off site testing. The end user side or the testing side is also called the development end.

In alpha testing it is necessary to determine whether the the software system is delivering the service as it was expected by the client or the customer. The environment in which the alpha testing is performed is called the client environment.

Some details about Pointers and Structures in C...

A pointer can be defined as a variable pointing to another variable or a variable storing the location or address of another variable.Pointers can be used to point to any data type.There are object pointers, function pointers, structure pointers and so on. Like any other pointers, structure pointers are also a very useful tool in C programming.Pointer structures are easy to declare and declared similarly like any other kind of pointer by putting a “*” sign before the name of the structure. See the example below:

Struct address *a1, *a2;
a1 = &b2;
a2 = &b3;

where b2 and b3 are the actual structure address variables. Using the below given assignment statement you can copy the details of structure pointed by a2 to a1:

*a1 = *a2;

Any member of a structure can be accessed using a pointer in the following way:
A->b

Here A is a pointer pointing to a structure and b is a data member or a member function of the structure being pointed. And there’s another way to access a member of a structure which has been given below:

(*A).b;

Both the statements are equivalent. Use of structure pointers is very common and useful.Be careful while dealing with structure pointers like any other normal pointer.The precedence of operators matters a lot. Be careful with the precedence of operators while programming in C.If we enclose *A is parentheses, an error will be generated and the code will not be compiled since the “.” Operator has got a high precedence than the”*” operator.Using so many parentheses can be quite a tedious job so, C allows us to use a shorthand notation to reduce the bombastic jargon. ” (*A).” can also be written as given below:

A ->

This is equivalent to (*A). but takes less characters. We can create pointers to structure arrays. A lot of space can be saved if we declare an array of pointers instead of an array to structures. In this only one structure is created and subsequently values are entered and disposed. Even structures can contain pointers as shown below:

Typedef struct
{
Char a[10];
Char *b;
} c;
c d;
char e[10];
gets(d.a,10);
d.b = (char *) malloc (sizeof (char[strlen(e)+ 1]));
strcpy(d.b, e);


This method is implemented when only a few records are required to be stored. When the size of the structure is large, it becomes difficult to pass and return the structures to the functions. To overcome this problem we can pass structure pointers to the functions. These structures can be accessed indirectly via pointers. Given below is a small code to illustrate the passing of structure pointers to the function and accessing them:

struct product
{
Int pno;
Float price;
};
Void inputpno (struct product *pnoptr);
Void outputpno (struct product *pnoptr);
Void main()
{
Struct product item;
Printf(“product details\n\n”);
Inputpno (&item);
Outputpno (&item);
}
Void outputpno (struct product *pnoptr)
{
Printf( “product no. = %d, price = %5.2f \n”, ( *pnoptr). Pno, (*pnoptr).price);
}
Void inputpno (struct product *pnoptr)
{
Int x;
Float y;
Struct product pno;
Printf( “product number: “);
Scanf( “%d”, &x);
( *pnoptr).pno = x;
Printf ( “price of the product: “);
Scanf( “%f”, &y);
( *pnoptr). Price = y;
}


In this program code, the prototypes, function calls and definitions have been changed in order to work with structure pointers. Dereferencing of a structure pointer is very common in programs. “->” (arrow) is an operator that is provided by C for accessing the member function of a structure. The 2 statements given below are equivalent:

Pnoptr -> pno;
(*pnoptr).pno;

What is a software process? What are different types of software process models?

A strategy that a software development team employs in order to build quality software is called software process. A software process is chosen based on:
- nature of the project and application.
- methods and tools to be used.
- management and work products that are required.

A software process consists of:
- Framework activities: People who are involved in the development process perform these activities. They are alsoknown as phases of the software development process.
- Tasks sets: The activities in the process framework defines a set of tasks. These tasks would have milestones, deliverables or work products and software quality assurance (SQA) points.
- Umbrella activities: These are the activities that supports the framework of activities as the software development project progresses such as software project management, change management, requirements management, risk management, formal technical reviews.

Types of Software Process Models
- Linear Sequential Model
- Prototyping Model
- Rapid Application Development (RAD) Model
- Evolutionary Process Models which includes Incremental Model, Spiral Model and
Component-based Assembly Model.
- Concurrent Development Model
- Formal Methods

Factors that Affect the Choice of Process Model
- Type of the Project
- Methods and Tools to be Used
- Requirements of the Stakeholders
- Common Sense and Judgment

Performing User Interface Design - Design Evaluation

Design should be evaluated to check whether it meets the user needs or not once an operational user interface prototype has been created. Evaluation spans a formality spectrum that ranges from an informal test drive in which a user provides an impromptu feedback to a formally designed study.

- After design model has been completed, a first level prototype is created.
- Prototype is evaluated by user.
- User provides designer with direct comments about the efficacy of interface.
- Evaluation cycle continues until no further modifications to interface design are necessary.
- Once first prototype is built, designer collects a variety of qualitative and quantitative data that will assist in evaluating the interface.
- Qualitative data includes questionnaires like simple yes/no, numeric response, scaled response, likert scales, percentage response or open ended.
- Quantitative data can be got by a form of time study analysis can be conducted.

The evaluation criterion applied during early design reviews are:
- length and complexity of written specification of the system.
- number of user tasks specified and average number of actions per task.
- number of actions, tasks, and system states indicated by the design model imply memory load.
- interface styles, help facilities, and error handling protocol provides an indication of interface complexity.

Interface Design Steps - Applying Interface Design Steps, User Interface Design Patterns and Design Issues

Interface design is an iterative process. Interface design activities commences once interface analysis has been completed. Each user interface design occurs a number of times, each elaborating and refining information developed. Interface designer begins with sketches of each interface state and then work backward to define objects, actions, and other important design information.

APPLYING INTERFACE DESIGN STEPS

- Definition of interface objects.
- Defining the actions that are applied to them.
- Description of a use case is written.
- Once objects and actions are defined and elaborated, they are categorized by type.
- Target, source and application objects are identified.
- A source objects is dragged and dropped onto a target object.
- Application objects represents application specific data that is not directly manipulated as part of screen interaction.
- Screen layout is performed once all objects and actions are defined.
- Screen layout is interactive process in which graphical design and placement of icons, major and minor menus, screen text is conducted.
- Although automated tools can be useful in developing layout prototypes, sometimes a pencil and paper are all that are needed.

USER INTERFACE DESIGN PATTERNS

- A wide variety of user interface design patterns have emerged.
- A design pattern is an abstraction that prescribes a design solution to a specific well bounded design problem.

DESIGN ISSUES

Four common design issues are:
- system response time: it is measured from the point at which the user performs some control action. its two main characteristics are length and variability.If system response is too long, user frustration and stress is the result.Variability refers to the deviation from average response time.
- user help facilities: design issues must be addressed when a help facility is considered.
- error information handling: A good error message should describe problem in language that a user can understand. An error message should provide constructive advice for recovering from error. The message should indicate any negative consequences of the error. The error message should be accompanied by an audible or visual cue and the message should be non-judgmental.
- command labeling: Conventions for command usage should be established across all applications.It is confusing and often error-prone for a user to type command. The potential of error obvious.

Unnecessary iteration, project delays, and customer frustration often result. It is better to establish a design issue to be considered at beginning of software design, when changes are easy and costs are low.

Overview of The Interaction Model - Use cases, Sequence diagrams, State diagrams, User interface prototype

The interaction model of web applications enables a conversation between an end user and application functionality, content, and behavior. Interaction model is made up of four elements:
- Use cases
- Sequence diagrams
- State diagrams
- User interface prototype

Some use cases describe the interactions between end user categories and the system. Other use cases refine the interactions, providing the analysis detail necessary to guide design and construction. Use cases provide a one-dimensional view of the interaction.

Sequence diagrams are a shorthand representation of the manner in which dynamic elements(user actions) collaborate with the structural elements(analysis classes) of the system. There is a need to ensure that traceability exists between the classes that have been defined and the use-cases that describe system interaction. Sequence diagrams can be created for each use-case once analysis classes are defined for the use case. Sequence diagrams present a second dimension that is more procedural in nature.

As the interaction occurs, state diagrams are another way to represent the dynamic behavior of the web application. State diagrams can be represented at different levels of abstraction. State diagrams provide a third dimension that is more behavioral and contains information about potential navigation pathways that is not provided by use cases or the sequence diagram.
Large complex web applications benefits from interaction model that encompasses the three representations : use cases, sequence diagrams and state diagrams.


User Interface Prototype : The layout of user interface, content it presents, interaction mechanisms, and overall aesthetic of user-web application connections have much to do with user satisfaction and the overall acceptance of the web application. User interface prototype is performed during the creation of analysis model.

Prototyping Software Life Cycle Model - a type of SDLC Model

Prototyping model starts with requirements gathering.The basic idea here is that instead of freezing the requirements before a design or coding can proceed, a throwaway prototype is built to understand the requirements. Prototyping is an attractive idea for complicated and large systems for which there is no manual process or existing system to help determining the requirements.
- Prototype is generally developed at the cost of the developer and not at the cost of the client.
- A prototype is developed using prototyping tools such as scripting languages or Rapid Application Development.
- Prototyping is generally required to obtain user interface requirements.
- In hardware, prototyping is used to prove your design concepts.

Advantages of Prototyping Model

- It is good for developing software for users who are not IT-literate.
- Errors can be detected much earlier as the system is mode side by side.
- Quicker user feedback is available leading to better solutions.
- Reduced time and costs.
- An SRS will be frozen after obtaining the feedback from the user.

Disadvantages of Prototyping Model

- Development cost is borne by the developer.
- Customer could believe the prototype as the working version.
- Users can begin to think that a prototype, intended to be thrown away, is actually a final system that merely needs to be finished or polished.
- Excessive development time of the prototype.
- Expense of implementing prototyping.