W5HH Principles.

In an excellent article on software process and projects, Barry Boehm [BOE96] said.

"You need an organizing principle of weighing by the [project] simple plans for simple projects to provide"

 Boehm proposes an approach that focuses on project objectives, milestones and timetables, responsibilities, management and technical approaches, and resources necessary. He calls it the principle WWWWWHH for a series of questions that lead to a definition of the main characteristics of the project and the resulting project plan:
1> Why is the system developed?
 The answer to this question all parties to the validity of the business reasons for the software to evaluate. Set in a different way, time not only business people and spending money?

2>What to do until then?
Answers to these questions to help the team a project schedule to establish the identification of key project tasks and objectives that the client is required.

3>Who is responsible for a function?
 Earlier in this chapter, we noted that the role and responsibility of each team member should be designated programs. The answer to this question helps achieve.

4> Where are they located organize? Not all the roles and responsibilities of living in the software team itself. , Customer users and other stakeholders also have responsibilities.

5> How will the work done technically and managerially? When product scope is established, a management and technical strategy for the project specified. How much of each resource is needed? The answer to this question is taking conducting evaluations based on answers to previous questions.

Product and Process.

If the process is weak, the end product will undoubtedly suffer, but a pathological excess in the process is also dangerous. In a short essay, Margaret Davis [DAV95] commentary on the duality of product and process: For every ten years, give or take five, the software community to redefine the "problem" by moving its focus on product issues to process issues . So we structured programming languages ​​(product), followed by structured analysis methods embrace (process), followed by data encapsulation (product) followed by the current emphasis on the Software Engineering Institute's Software Capability Maturity Model Development (process ).

 While the natural tendency for the pendulum to unwind at a point midway between two extremes, the software community's focus shifted constantly as the new force is applied when the last swing it. These fluctuations are harmful in themselves, because they confuse the average software practitioner radically changing what it means to do the job, leaving it well.

Cadence also solve the "problem" because they are destined to fail as long as product and process is seen as forming a dichotomy instead of a dual. There is no advantage in the scientific community notions of duality when discrepancies promoting observations can not be explained fully by any competing theory. Dual nature of light that seemed to simultaneously wave and particle are taken since 1920 when Louis de Broglie proposed it. I believe we can make observations of objects of the software and its development reflects a fundamental duality between product and process. You can not derive or understand the full purpose, its context, the use, meaning and value when you see it as just a process or just a product. . .

extra sizing..

"Fuzzy Logic" sizing.

 This approach uses approximate reasoning techniques that are the cornerstone of fuzzy logic. To this approach, the planner must identify the type of application, the reasons for its size on a qualitative scale, and then refine the magnitude within the original series. Although personal experiences may be used, the planner should also have access to a historical database projects8 have so that estimates can be compared with actual experience. 

Function Point Sizing. The planner develops estimates of the information domain characteristics discussed in Chapter 4. Standard Component Sizing. Software consists of a number of different "standard components", are generally for a specific application area. For example, the standard components of an information system subsystems, modules, screens, reports, interactive programs, batch programs, files, LOC, and object-level statements. The project planner estimates the number of occurrences of each standard component and then uses historical project data, the delivered quantity per standard component to be determined. to illustrate, consider an information systems application. The planners estimated that 18 reports will be generated. Historical data show that 967 lines of COBOL [PUT92] are required per report. This allows planners estimate that 17 000 LOC required for the reports component. Similar calculations are estimates, and other standard components, and a combined size value (statistically adjusted) results.

 Change sizing. This approach is used when a project involves the use of existing software to be modified in any respect as part and parcel of a project. The planner estimates the number and type (eg re-use, adding code, code change, delete code) of changes that must be performed. With an "expense ratio" [PUT92] for any kind of change, the magnitude of change can be estimated.

software sizing

The accuracy of a software project estimate is based on a number of things:

 (1) the extent to which the planner has properly estimated the size of the product to be built,
 (2) the ability to estimate the size of the human effort to translate, calendar time and dollars (a function of the availability of reliable software metrics from past projects),
 (3) the extent to which the project plan reflects the capabilities of the software team, and
(4) the stability of the product requirements and the environment that supports the software engineering effort..

What is software?

 Software is a::

(1) instructions (computer software) that when executed provide desired function and performance, .

(2) data structures that enable programs to adequately manipulate information, ..

and

(3) documents describing the operation and use of program. There is no doubt that other, more detailed definitions will be provided. But we need more than a formal definition...

Increment model:

The larger model combines elements of the linear sequential model (applied repeatedly) with the iterative philosophy of prototyping. Refer to Figure 2.7, the additional model applies linear sequences in a staggered manner as calendar time progresses. Each linear sequence produces a deliverable "increment" of the software [MDE93]. For example, the advanced word processing software progressive paradigm to basic file management, editing and document production capabilities to do for the first time overturned, more sophisticated editing and document production capabilities in the second generation, spelling and grammar in the third capsized and advanced page layout capabilities in the fourth pass. It should be noted that the process flow for an increase may include prototyping paradigm. When a stepwise model, the first increase is often a core product. These are the basic requirements are addressed, but many extra features (some known, others unknown) remains unresolved. The core product of the client (or undergo a thorough review). Due to the use and / or evaluation prepared a plan for the next interval. The plan focuses on changing the core product to better meet customer needs and providing additional features and functions.

paradigm is also problematic for the following reasons in the model of prototyping: paradigm is also problematic for the following reasons:

 1 The customer gets what appears to be a working version of the software, aware of the fact that the prototype took place, and "the wire Rubber and bales, "not knowing the race to make it work does not consider the overall quality of the software and the long-term sustainability. Once you know that the product should be rebuilt to a high standard of service quality, customer cry poor and say that "some corrections" applied to a product prototype. Too often, grants management software development. 2. The developer often makes implementation compromises to develop a prototype to quickly find a job. The right operating system or programming language can only be used in what is available and known to be an inefficient algorithm can be implemented to demonstrate the ability. After a while ', the developer can get used to the elections and forget why they would have to be adjusted. The less than ideal solution, is now an important part of the system. Although problems may occur, may be an effective prototyping software development paradigm. The key is to change the rules of the game to begin with, it is the customer and developer must both agree that the prototype is based on a mechanism for defining requirements. then discarded (at least in part), and the actual software and is designed just for the quality and sustainability ..