Project Manager - Keeping the morale of people up

The job of a Project Manager in a software project is a complex one. Technically, the Project Manager is supposed to lead the project in the best possible manner, and try his / her best to understand the issues faced in the project, raise them to the best possible manner in order to resolve it and keep as much as on schedule as possible.
In reality, the Project Manager is the person who is the last resort person. He or she is the one who needs to understand issues which have rose in terms of complexity and drive /delegate the process of resolving the problem. This may also include resolving issues related to morale within the team.
Now, morale can be a team problem, or it can be a problem with specific members of the team. I remember a large project I was involved with, critical to the future of our team. Rumors started floating in that the project was being cancelled since the client was dis-satisfied and would drop the project. However, senior management was not conveying any sort of decision and team members were getting very low in morale, with the subconsious feeling about why work so hard for customization for a client where the project would be dropped.
It is in such a situation that the Project Manager and the team leads have to play a critical role. One part is to try to find out from senior management about whether the project is indeed being cancelled, or was there a chance. Once the status is know as well as knowledge about what parts can be shared with the team, it is important to share status with the team on an ongoing basis. Getting information from rumors can be incredibly bad for morale, it is better to discuss within the team, take questions and ensure that people are in a better way, and getting into such a discussion helps (and this is applicable not just in a case where the project may be cancelled, but there may be other issues that could cause morale problems).
More tricky is the case where one or more of the team members are having morale issues, or some other emotional issues. This is tricky to resolve when this kind of problem is causing productivity issues (and in a lot of morale and emotional issues, there will be impacts on productivity). It is the responsibility of the Project Manager and the team leads to identify cases where a team member might be having some kind of morale issues. This kind of becomes critical when there is an associated impact on productivity. Discussion needs to happen with the team member, although the discussion can become very limited if the issue is more of a personal or family nature, something that the manager needs to handle with some delicacy. What cannot be left unsaid, whether delicately or clearly, is that the impact on productivity needs to be set right - the Project Manager would be remiss in his or her duty if this is not handled well. 

What kinds of functions are used by Cleanroom Software Engineering approach?

Harlan Mills and his colleagues namely Linger, Poore, Dyer in the year of 1980 developed a software process that could promise building zero error software at IBM. This process is now popularly known as the Cleanroom software engineering. The process was named in accordance with an analogy with the manufacturing process of the semiconductors. 

The Clean room software engineering process makes use of the statistical process and its control features. The software systems and applications thus produced have certified software reliability. The productivity is also increased as the software has no defects at delivery. 

Below mentioned are some key features of the Cleanroom software engineering process:

1. Usage scenarios
2. Incremental development
3. Incremental release
4. Statistical modeling
5. Separate development
6. Acceptance testing
7. No unit testing
8. No debugging
9. Formal reviews with verification conditions

Basic technologies used by the CSE approach are:

1. Incremental development
2. Box structured specifications
3. Statistical usage testing
4. Function theoretic verification

- The incremental development phase of the CSE involves overlapping of the incremental development and from beginning of specification to the end of the test execution it takes around 12 – 18 weeks.

- Partitioning of the increments is critical as well as difficult. 

- Formal specification of the CSE process involves the following:

1. Box structured Designing: Three types of boxes are identified namely black box, state box and clear box.
2. Verification properties of the structures and
3. Program functions: These are one kind of functions that are used by the clean room approach.

- State boxes are the description of the state of the system in terms of data structures such as sequences, sets, lists, records, relations and maps. 

- Further, they include specification of operations and state in-variants.

- Each and every operation that is carried out needs to take care of the invariant. 

- The syntax errors present in a constructed program in clean-room are checked by a parser but is not run by the developer.

- A team review is responsible for performing verification which is driven by a number of verification conditions. 

- Productivity is increased by 3–5 times in the verification process as compared to the debugging process. 

- Proving the program is always an option with the developers but it calls for a lot of math intensive work.

- As an alternate to this, clean room software engineering approach prefers to use a team code inspection in terms of two things namely:

1. Program functions and
2. Verification conditions

- After this, an informal review is carried out which confirms whether all conditions have been satisfied or not. 

- Program functions are nothing but functions describing the prime program’s function.

- Functional verification steps are:

1.    Specifying the program by post and pre-conditions.

2.    Parsing the program in to prime numbers.

3.    Determining the program functions for SESE’s.

4.    Defining verification conditions.

5.    Inspection of all the verification conditions.

- Program functions also define the conditions under which a program can be executed legally. Such program functions are called pre-conditions.

- Program functions can even express the effect the program execution is having up on the state of the system. Such program functions are called the post conditions.

- Programs are mostly expressed on terms of the input arguments, instance variables and return values of the program. 

- However, they cannot be expressed by local program variables. 

- The concept of nested blocks is supported by a number of modern programming languages and structured programs always require well nesting. 

- The process determining SESE’s also involves parsing rather than just program functions.

What are the core practices of extreme programming?

Over the time the extreme programming has proved itself to be a great helping hand as an agile practice in improving the overall quality and productivity of the software products according to the ever changing requirements of the customer.
Being an agile practice it frequently releases software products with the short development cycle which is achieved through time boxing. During the whole process several check points are introduced in to the development cycle where the new customer requirements can be easily incorporated in to the software system.

Elements of Extreme Programming

There are several elements of the extreme programming like:
1. Pair programming
2. Extensive code review
3. Unit testing
4. Maintain simplicity and clarity of the code
5. Providing a flat management structure and so on.

Values of Extreme Programming

The extreme programming is guided by values, rules and principles! There are 5 values namely:
1. Communication
2. Simplicity
3. Feedback
4. Courage
5. Respect

Principles of Extreme Programming

The rules of the extreme programming govern its all time activities. Three basic principles have been defined for the extreme programming as mentioned below:
1. Feedback
2. Assuming simplicity
3. Embracing change

core Practices of Extreme Programming

The extreme programming is said to be composed of 12 practices which is what we going to discuss in this article. The 12 practices have been grouped into sets of four:

1. Fine Scale Feedback: This area involves 4 following practices:
(a) Programming in pairs: This agile practice involves 2 programmers working side by side one of which is a driver and other is an observer. The driver is suppose to type in the code while the observer holds the duty to review each line of the code typed.

(b) Planning game: This is the most important practice in the extreme programming. The game here is the name given to a meeting that is held once for every iteration of the development process with the purpose of guiding the product in to delivery. It has 2 parts:
- Release planning: It has 3 phases:
    + Exploration phase
    + Commitment phase
    + Steering phase
- Iteration planning: It too has got the same phases as the release planning.

(c) Test driven development or TDD: This is another agile practice relying on the iterative and incremental approach and refactoring of the code for improving its overall design.

(d) Whole team: Extreme programming forces the need of the customer availability at all the times for questions.

2. Continuous Process: This process is constituted of the following 3 practices:

(a) Continuous integration: In extreme programming it is required that only the latest version of the software system or application is worked up on.  The current version of the software that is available with the different team members must be uploaded to the code repository in every few hours since this avoids delays in the project cycle.

(b) Design improvement or re-factoring of the code: Since only the required functionalities are implemented, this may cause the system to hang. This may require dual maintenance then. In such cases changes in one part of the program affect the other parts of the code. At such times the refactoring of the code is needed.

(c) Small releases: The software is delivered via the frequent releases of the live functionalities. With these small releases the customers gains the confident about the progress of the development and the concept of the “whole team” is also maintained. The customer as well is able to come up with the suggestions regarding the development of the software.

3. Shared Understanding: This involves the following 4 practices:
(a) Coding standards
(b) Collective code ownership
(c) System metaphor
(d) Simple design

4. Programmer Welfare: It involves development at a “sustainable pace”.

What is meant by time boxed iterative development?

The iterative type of the agile software development has always been the favourite choice of the developers and testers when it comes to adopting a time and effort efficient and effective agile software development process. 

Till now three approaches to the iterative development have been developed namely:

      1. Risk based iterative development

      2. Client based iterative development

      3. Time boxed iterative development

This article is here to focus up on the time boxed iterative development. But before we move on to the time boxed iterative development, let us brief up ourselves with the concepts of the iterative and incremental development so that it will be easy for us to understand the time boxed iterative development better.  

What is Iterative Development?

- Iterative and incremental development is an essential part of the agile software development process and lies at the heart of it.

- The iterative came in to existence as a response to the weaknesses of the other agile software development models especially the waterfall model.

- Apart from just being an essential part of the agile software development, it is also necessary to the extreme programming, rational unified process and many other agile software development frame works. 

- It is based up on a similar process of the business process improvement. 

- The iterative development is a way to develop a whole software system or application in small steps via the repeated cycles at a time. 

- There are two approaches that can be followed for accomplishing a task:

   1. We can either work non stop to accomplish the goal or

   2. We can define a time limit for ourselves and achieve as how much we can in that time period. 

The second approach is called time boxing. 

What is a Time Boxed Approach?

- It is a simple one yet effective technique from the perspective of planning and over the years has been found effective in completing the jobs within a time limit. 

- If we look at this approach from the perspective of planning, it is found to be useful in the development processes which are involved with the development of a complex software system or application and the starting point is quite uncertain. 

- On the other hand if we look at it from the perspective of the personal development, it is extremely helpful in improving the effectiveness as well as the productivity.

- In fact this approach is quite easy to follow but requires maximum effort. 

- Using time boxing approach, you fix up a time period and try to achieve the maximum you can within that time frame. 

What is meant by Time Boxed Iterative Development

- Time boxing approach employed for the iterative development is termed as the time boxed iterative development. 

- In such an approach to iterative development the task is divided in to several small iterations and each iteration is provided with a time box.

- Each of these iterations has its own budget, deadline and the deliverable. 

- In some cases, time boxing iterative development is employed for managing the risk.

- Since it is important to meet deadlines, it is necessary that the deadlines are not changed without the prior permission of the project owner. 

- An inadequate breakdown of the task can lead to the underestimation of the time requirement of the project. 

- To avoid changing of the deadline following three points can be followed:

1. Reduction in the scope: requirements having lower impact can be dropped from the plan.
2. Keeping time as the fixed constraint throughout.
3. Increase in the cost: the resources and the over timing can be added in to the plan.

Many projects that have been developed with the time boxing technique have been reported to be successful. 

Black Box Testing Technique - Orthogonal Array Testing (OATS)

Orthogonal array testing enables you to design test cases that provide maximum test coverage with reasonable number of test cases. This type of testing can be applied to problems which has relatively small input domain but too large to accommodate exhaustive testing. Orthogonal array testing is more suitable in finding errors associated with faulty logic within a software component.

Orthogonal arrays are two dimensional arrays of numbers which possess the interesting quality that by choosing any two columns in the array you receive an even distribution of all the pair-wise combinations of values in the array.

The benefits of orthogonal array testing includes:
- lower execution time.
- lower implementation time.
- code coverage is high.
- overall productivity increases.
- the analysis of results take less time.

Orthogonal array testing uses the following terminology:
- Runs are the number of rows in an array.
- Factors are the number of columns in an array.
- Levels are the maximum number of values that can be taken on by any single factor.

Orthogonal array testing (OAT) helps in optimizing testing by creating an optimized test suite, detects all kind of faults, guarantees the testing of pair wise combinations, less prone to errors, simpler to generate and is independent of platforms and domains.

Team Software Process (TSP) - Framework Activities and Phases

Team Software Process (TSP) scripts define elements of the team process and the following framework activities:

- LAUNCH
It reviews course objectives and describes the TSPi structure and content. It assigns teams and roles to students and describes the customer needs statement. It also establishes team and individual goals.
- STRATEGY
It creates a conceptual design for the product and establishes the development strategy and decide what will be produced in each cycle. Strategy makes initial size and effort estimates and establish a configuration management plan, reuse plan and risk management.
- PLAN
It estimates the size of each artifact to be developed. Planning also identifies tasks to be performed, estimates time to complete each task;, assign tasks to team members, make a weekly schedule for task completion and make a quality plan.
- REQUIREMENTS
Requirements analyze need statements and interview the customers, specify and inspect the requirements and develop a system test plan.
- DESIGN
It creates a high-level design, specify the design, inspect the design, develop an integration test plan.
- IMPLEMENT
Implementation uses the PSP to implement modules/units, creates detailed design of modules/units, reviews the design, translates the design to code, review the code,
compile and test the modules/units and analyze the quality of the modules/units.
- TEST
Testing builds and integrate the system. It conducts a system test and produce user documentation.
- POSTMORTEM
It conducts a postmortem analysis, writes a cycle report and produce peer and team evaluations.

TSP makes use of a wide variety of scripts, forms, and standards that serve to guide team members in their work. Scripts defines specific process activities and other more detailed work functions that are part of the team process.
TSP recognizes that the best software teams are self directed. Team members set project objectives, adapt the process to meet their needs, have control over schedule, and through measurement and analysis of the metrics collected, work continually to improve team's approach to software engineering.

Team Software Process (TSP) - Strategy and Objectives

The goal of Team Software Process (TSP) is to build a self directed project team that organizes itself to produce high quality software. The objectives of TSP are:
- The TSP is intended to improve the levels of quality and productivity of a team's software development project.
- Using TSP, organizations establish a mature and disciplined engineering practice that produces secure, reliable software in less time and at lower costs.
- Accelerate software process improvement by making CMM level 5 behavior normal and expected.
- Show managers how to coach and motivate their teams and how to help them to sustain peak performance.
- Build self directed teams that plan and track their work, establish goals, and own their processes and plans. To form a self directed team, you must collaborate well internally and communicate well externally.

A self directed team should do the following:
- understand overall goals and objectives.
- defines roles and responsibilities for each team member.
- tracks quantitative project data.
- identifies a team process appropriate for project.
- implementing strategy for the process.
- defines local standards.
- assess risk and reacts to it.
- tracks, reports and manages project status.

TEAM SOFTWARE PROCESS (TSP) STRATEGY

- Provide a simple process framework based on the PSP.
- Use modest, well-defined problems.
- Develop products in several cycles.
- Establish standard measures for quality and performance.
- Provide detailed role definitions.
- Use role and team evaluations.
- Require process discipline.
- Provide guidance on teamwork problems.

Software Development Metrics : Product and Productivity Metrics

Metrics are needed to understand the level of process performance, project performance and product performance. They are needed to set goals and measure the trend and rate of improvement. Criteria for effective metrics are:
- Simple.
- Keep them to a minimum.
- Base them on business objectives and the business process - avoid those that cause dysfunctional behavior.
- Keep them practical.

Product Metrics

One accepted method of estimating the size of the product is using the metric KDSI (Kilo or Thousand Delivered Source Instruction) or Kilo Lines of Code (KLOC) - how many thousands of lines of code are required for the project excluding the comments. Based on KDSI, a project can be categorized as small, intermediate, medium, large or very large.
- Small <= 2 KDSI
- Intermediate >2 and <=8 KDSI
- Medium >8 and <=32 KDSI
- Large >32 and <=128 KDSI
- Very large >128 KDSI

Productivity Metrics

Another metric that can be used for measuring the productivity of the programmer is counting the number of lines that can be written by a programmer in one hour i.e. the Delivered Source Instructions (DSI) per hour.
Time required for execution of a project(in hours) = Total KDSI of the project/average KDSI per hour.