One of the hardest things to do is to discover the simplest solution to a problem

Too often software developers come up with the most complex solution instead of the simplest one. The simplest solution is the solution with the least amount of functionality to solve the problem. This makes the solution simple to design, simple to code, and simple to test too. Another advantage of simple solutions it is easy to document and communicate.

A project has four phases which roughly correspond to the first four main stages of the waterfall model: requirements definition, system and software design, implementation and unit testing, and integration and system testing. In the inception phase the business case and the financial forecast are created as well as a use-case model, a risk assessment and project description. The elaboration phase is used to perform problem domain analysis and to shape the architecture. During the construction phase the development and integration of components are the central activities. Finally, the transition phase the software system that is developed will be implemented at the customer’s organization.

We provide tips on seeing project status, developing and managing the project portfolio, and providing feedback to people. We perform process assessments for an entire product development process; assessment is an act of reasoning, it is what we should do before taking a decision. However, when large amounts of data are involved, assessment gets complicated because project managers are just not equipped to handle many details. We may help by employing our experience and knowledge.

Contact us now!

Contact us now!

to start planning

SOFTWARE PROJECT EFFORT ESTIMATION

I get asked the question, “What is the average cost of develop software?” all the time.  The answer depends. Efficient development of software requires accurate estimates. Unfortunately, software development effort estimates are notorious for being too optimistic, and there seems to have been no substantial improvement in estimation accuracy over the years. Inaccurate software estimates cause trouble in business processes related to software development such as project feasibility analyses, budgeting and planning. Even small improvements will be valuable because of the large scale of software development. Failing to properly estimate your project can result in the effort being held up against an unrealistic measurement. Your project could be progressing smoothly, but appear an abysmal failure because of unrealistic expectations. Guidelines for developing proper estimates should be developed within the organization and formalized as part of your organization’s project-delivery methodology. Having a consistent way of conducting estimates includes engaging the right people at the right time in the project’s life cycle to perform the estimate.

No estimate is guaranteed to be accurate. People get sick or leave the organization, teams run into unforeseen technical problems, the needs of the organization change. The unexpected will almost certainly happen. Therefore, the goal of estimation is not to predict the future. For example, any disagreement is generally about what is required to perform the task itself, not about the effort required to complete it. A project manager can help the team to create more accurate estimates by reducing the uncertainty about the project.

Senior managers are often willing to take the programmers’ estimates at face value, even when those estimates are clearly padded. This is because, to them, programming is opaque: managers and stakeholders don’t understand how code is written, so they assume that all programming tasks are difficult. Distrust in a software organization can be a serious, endemic problem. It starts with a kernel of distrust between management and the engineering team; the distrust grows until management simply won’t accept the team’s estimates. If deadlines are handed down that do not allow enough time for the team to complete the work, it can lead to serious morale problems—and the project manager will be blamed for the delay, often by the same people who caused it in the first place.

An important part of running successful software projects is reaching a common understanding between the engineers, managers, and stakeholders. One way to do that is with a consistent set of practices. This is why we consider project estimation one of the most important parts from a project.

EFFORT DISTRIBUTION ACROSS LIFECYCLE

An open question in research on software engineering process effort is to find out: “What is an effective distribution of effort over disciplines? In older, traditional environments, software development phase was typically 60 percent of the project lifecycle.  In newer environments, there is typically a greater percentage of effort spent in the earlier phases and less time spent in the development phase. You may use this information  as a sanity check for assessing the relative distribution of effort across the software development life cycle.

It turns out there is a relationship between how a software organization spends its time and productivity. The more time it spends in coding and testing the lower the software productivity and quality rates. Those organizations that spend the most time in requirements and analysis have the highest productivity rates. The data is conclusive on this point.

Effort distribution by phase or activity is an important but often overlooked aspect compared to other steps in the cost estimation process. Poor effort allocation is among the major root causes of rework due to insufficiently resourced early activities; comes from lack of recognition to process variations and lack of understanding to process effort distribution patterns.

Our empirically-based consultancy offers various beneficial outcomes in developing better understanding to development phase focuses and predicting cost estimation and phase allocation. A software application is in essence a defined set of elementary processes. When these elementary processes are combined they interact to form what we call a software system or software application. An elementary process is not totally independent existing alone, but the elementary processes are woven together becoming interdependent. Management needs the ability to step back from the details and see the bigger, complete picture. In project management it is important to take decisions based on facts and not on intuition.