13703 Views
1 Likes
0 Comments

The ultimate management sin is to waste people’s time, Tom DeMarco and Timothy Lister told us in their famous book Peopleware [1]. This includes having pointless meetings that prevent people from actually doing anything useful. Nevertheless, some meetings are considered a necessary evil and therefore the so-called “agile movement” in software development has come up with an efficient way of dealing with this: the Stand-up Meeting in 15 Minutes. For those who have just woken up from ten years of hibernation, or having emerged from a cave that had no Internet access, I will explain this briefly.

A stand-up meeting is a daily meeting where people remain standing up to keep the duration of the meeting under 15 minutes. Teams use these meetings to answer three simple questions..

29625 Views
12 Likes
0 Comments

Software production has become one of the key activities of the industrialized world. Software applications are now the driving force of business, government operations, military equipment, and most of the services that we take for granted: electric power, water supplies, telephones, and transportation.

Most major companies and government agencies build or commission new software applications every year. But software development and software contracts have been very troublesome. Cost and schedule overruns are common, and litigation for software problems is a frequent outcome. Successful development of large software projects is so difficult that significant percentage of large systems greater than 10,000 function points are canceled and never completed.

One of the major challenges of software cost and schedule estimation is “sizing” or predicting the amount of source code and other deliverables that must be built to satisfy the requirements of a software application. Sizing is a critical precursor to software cost estimating whether estimation is done manually or by means of a commercial software cost estimating tool.

For software applications that are similar to existing applications, size can be derived by analogy to the existing packages. When the software application is a new kind of application then sizing by analogy is not a feasible approach.

For much of the history of the software industry, sizing was considered a very difficult and intractable problem. Sizing is still difficult, but over the past 30 years an interesting new methodology for dealing with size prediction has been developed based on the use of the function point metric. This new methodology has the advantage that it can not only predict the volume of source code, but also the volumes of planning documents, specifications, user manuals, test cases, and even the probable number of errors or bugs that might be encountered.

 

 

 

Author: Capers Jones is the President of Capers Jones & Associates LLC. He is also the founder and former chairman of Software Productivity Research, LLC (SPR), where he holds the title of Chief Scientist Emeritus. He is a well-known author and international public speaker, and has authored the books “Patterns of Software Systems Failure and Success,” “Applied Software Measurement,” “Software Quality: Analysis and Guidelines for Success,” “Software Cost Estimation,” and “Software Assessments, Benchmarks, and Best Practices.” Jones and his colleagues from SPR have collected historical data from more than 600 corporations and more than 30 government organizations. This historical data is a key resource for judging the effectiveness of software process improvement methods. The total volume of projects studied now exceeds 12,000. 

Copyright * 2008 by Capers Jones & Associates LLC.  All Rights Reserved.

19638 Views
3 Likes
0 Comments

The Volere requirements techniques were developed to answer the need for a common language for discovering requirements and connecting them to solutions. The language needs to be understandable by business people, customers, business analysts, engineers, designers, suppliers, testers or anyone else whose input is needed. All of these people have different skills and, not surprisingly, different views of what is important. A language intended for all of these people must recognise the differences in peoples’ viewpoints and yet have a consistent way of communicating and tracing the
relevant knowledge. This realisation that requirements is a socio-technical discipline has a strong influence on the development of the techniques.

Author: Suzanne Robertson & James Robertson, The Atlantic Systems Guild

159540 Views
100 Likes
12 Comments

Failing to properly and accurately define requirements at the very beginning of the project lifecycle points to a distinct lack of business analysis competency. The role of the business analyst is an important one, and, sadly, one that is underutilized by many organizations around the world. In essence, a business analyst acts as a translator or liaison between the customer or user and the person or group attempting to meet user needs. But, that’s just speaking generally. What about the specifics?

Below, I’ve put together a list of eight key competencies that every business analyst—or every professional performing the duties of a business analyst—should possess. I’ve included specific emphasis on tasks associated with junior, intermediate and senior business analysts. If performed effectively, the items on this list could save organizations millions.

19279 Views
9 Likes
0 Comments

In my last column I introduced you to the role of a typical security analyst, and explained that security is a part of the business lifecycle. In this column, I will dive into that concept, and I will highlight some of the areas a security analyst might play in determining the risk to an asset throughout its life span.

So what is a ‘lifecycle’ in business terms? There are many definitions, and if you ask any modern analyst you will get their own tweaked version of that answer. For our sake, let’s say a lifecycle is the cycle of life of a business asset from birth through to an end stage.

12763 Views
4 Likes
1 Comments

One of the issues high on the agenda of many CIOs is to align IT efforts with the company’s strategic goals. But how you do trace a line of code back to the strategic goal that caused it to be written? If we’re able to do this then, and only then, can it be said that IT is aligned with the business strategy. 

5404 Views
0 Likes
0 Comments
Over my last two articles, I have laid a foundation for a Service Oriented Architecture (SOA) as the enterprise architecture of the globally integrated enterprise and focused on how to define and establish the business side of the enterprise through a well defined business architecture . Before diving into the IT side of the enterprise, this articl...
16688 Views
1 Likes
0 Comments

In the past I have discussed the need to manage data (and all information resources) as a valuable resource; something to be shared and reused in order to eliminate redundancy and promote system integration.  Now, our attention turns to how data should be defined.  Well defined data elements are needed in order to properly design the logical data base as well as developing a suitable physical implementation.

25089 Views
14 Likes
0 Comments

The subject of current systems analysis is usually greeted with dismay or disdain by systems departments. There are many reasons for this. In many installations, the support of current systems takes more than 85% of the systems department's time, and the departments are more than ready to get on with new systems development and bury the old, non-working systems as quickly as possible. In cases where systems do not require a lot of maintenance, the systems department may find that the current systems are not giving management the kind of information it needs for effective decision making; these current systems become likely candidates for replacement.

However, there are some very legitimate reasons for documenting existing systems...

23962 Views
2 Likes
0 Comments

"As I discussed my May article for Modern Analyst, there's a lot of hype about the role of requirements in agile projects. Many people think you don’t “do” requirements on an agile project. Hogwash. Indeed, agile projects use requirements—but just enough requirements at just the right time."

In this article Ellen covers a number of agile requirements topics including:

  • Agile requirements need to be understood in context of the product, release, and iteration
  • Balancing Business and Technical Value
  • The Product Workshop
  • Release Workshops
  • Iteration Workshops
12233 Views
2 Likes
1 Comments

A colleague of mine asked me recently what makes a good Business Analyst, and this stumped me for a while. I had a rare opportunity to go trout fly-fishing recently and as the fishing was slow I was able to contemplate this question. You will gather from this that the question had worried me as I seldom think about work stuff when I am fly-fishing. 

So what does make a good Business Analyst? 

I decided to go back to basics; if I want to know what makes a good Analyst then I need to ask what do we, as Business Analysts, do? If I could understand that, then I can start to understand what makes one Analyst better than another.  

I asked around in business analysis circles for an on line description of what we do. Although I got a few different answers, I found I got the most consensuses with “a Business Analyst elicits, documents, and communicates business requirements”. But what does that mean?

10150 Views
6 Likes
1 Comments

That unfamiliar voice at the table was an IT Security Analyst, facing a common challenge in the modern day business, getting the project implemented, while ensuring the right security controls are in place.

Where a Business Analyst typically looks at requirements for a project to meet the objectives of the business, or a Systems Analyst looks at the needs of the technology to enable the business to meet the objective, a Security Analyst has too look at the dream.  The “dream” encompasses “we would like to make money” to “we are opening up this firewall port” and everything in-between.

The overall goal of the Security Analyst is finding and mitigating risk to the business, the businesses assets, and the technology infrastructure both current and future. We need to take in an insane amount of factors in about a project and calculate threats, vulnerabilities, and the likelihood of exploitation of these. Mix it in with a little gut feelings based on experience, and inform the business that what they want to do may introduce or magnify risk to their organization.

11240 Views
1 Likes
0 Comments

One of the biggest challenges in any system design effort is to produce a viable system design that is well thought-out with all of the pieces and parts working harmoniously together. If something is forgotten, regardless of its seeming insignificance, it will undoubtedly cause costly problems later on. The task, therefore, is to produce a design that is demonstratively correct.

6441 Views
0 Likes
0 Comments
Tony Bear says the BPM-folks are from Venus and the WS-folks from Mars. That exactly summarizes a big division in the BPM industry that might not be obvious. The term BPM-folks refers to the people that focus on process modelling. Their starting point is the analysis of procedures that describe how people and systems work together in an organisati...
13488 Views
2 Likes
1 Comments

In a nutshell, the concept of "stepwise refinement" is to take an object and move it from a general perspective to a precise level of detail. Architects have used such an approach for years, as have engineers building products. But to do so, they realized they cannot simply go from the general to the specific in one felled swoop, but instead, in increments (steps). The number of steps needed to decompose an object into sufficient detail is ultimately based on the inherent nature of the object. To illustrate, for architects designing a building, the typical steps include:

  1. Develop artist rendering (to consider viability).
  2. Design foundation and superstructure.
  3. Design Floor plans.
  4. Design electrical and plumbing diagrams.

Author: Tim Bryce

Page 72 of 84First   Previous   67  68  69  70  71  [72]  73  74  75  76  Next   Last   

 



 




Copyright 2006-2024 by Modern Analyst Media LLC