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 ..

linear model:.

 the need of linear process model, software requirements analysis. The requirements gathering process is strengthened and focused specifically on software. To understand the nature of the program (s) to be built, the software engineer ("analyst"), the information domain for the software, as well as required function, behavior, performance and interface means. Requirements for both the system and software are documented and reviewed with the customer. Design. Software design is a multi-process Actually It focuses on four different attributes of a program: data structure, software architecture, interface representations, and procedural (algorithmic) detail. The design process translates requirements into a representation of the software quality assessments for coding begins. Like requirements, the design documented and become part of the software configuration. Code Generation. The design must be translated into a machine-readable form. The code generation step Perform this task. If design is performed in a detailed Sage, code generation can be achieved mechanistically. Test. Once code is generated, program testing begins. The testing process focuses on the logical operation of the software to ensure that all settings tested, and the functional internal and external, that is conducting tests errors uncovered and ensure defined input will produce actual results that agree with expected results. Support. Software will definitely undergo change once it is delivered to the client (a possible exception is embedded software). Change will happen because I'm wrong because the software must be adapted to the changes in the external environment (eg, due to a change needed a new operating system or peripheral), or because the customer requires functional or improvements accommodate. Software support / maintenance reapplies each of the preceding phases of an existing program rather than a new one ..

five levels of process maturity.

five levels of process maturity, which are defined as follows:

 Level 1: Home.

 The software process is characterized as ad hoc and sometimes chaotic. Few processes defined and success depends on individual effort.

Level 2: Repeatable.

 based management processes in projects established to track cost, schedule and functionality. necessary process discipline is in place to repeat earlier successes on projects with similar applications.

 Level 3: Defined.

The process of software for business management and engineering is documented, and integrated into a standard software process across the organization. All projects use a documented and approved version of the process of organizational development and software support. This level includes all characteristics defined for level 2.

 Level 4: Manage.

The rules of the software process and product quality are collected. Both the software process and products are quantitatively understood and controlled with detailed measurements. This level includes all characteristics defined for level 3.

Level 5: Optimization.

 continuous process improvement is enabled by quantitative information and the process of testing ideas and innovative technologies. This level includes all characteristics defined for level 4.

myth of a software management myth.

 1>Myths and Management.

 Managers with responsibilities like managing software in most disciplines, often under pressure of budgets to maintain, keep schedules from slipping, and improve quality. If a person drowned in a straw snap, snap a driver software often believe in a myth software, if the trust will print (even temporarily) reduced. Myth: We have a book full of standards and procedures for building software will not let people give me everything they need to really get to know: The book of standards may very well exist, but it used? Software practitioners are aware of its existence? Will it reflect modern software engineering practice? Is it complete? Is streamlined time to improve service delivery, while another focuses on maintaining quality? In many cases the answer to all these questions is "no." Myth: My people have state-of-art software, after all, we buy their new computers. Reality: It takes a lot more than last mainframe model workstation or PC, high quality software development. Computer Aided Software Engineering (CASE) tools are more important than hardware to achieve quality and productivity, but most software developers still use them effectively.

 2> Client myths

 A client who is a computer software program, a person at the next table, a technical group down the hall / marketing sales department or an outside company that requested the software contract. In many cases, the customer believes myths about software because software managers and practitioners improve much misinformation. Myths lead to false expectations (by the client) and ultimately, dissatisfaction with the developer. Myth: A general statement of objectives is sufficient to begin writing programs-we can fill in the details later. Reality: A definition of a weak up front is the leading cause of failed software efforts. A formal and detailed description of the information domain, function, behavior, performance, interfaces, design constraints and evaluation criteria are essential. These properties can only be determined after thorough communication between customer and developer. Myths 

3> doctor.

 Myths still believed by doctors from the program by 50 years of cultural development are guided. During the early days of software development was considered an art form. Old ways and attitudes die hard. Myth: If we write the program and get to work, our work done. Reality: Someone once said that "The sooner you start writing code, the longer it will take to get done." Current data ([LIE80] [JON91] [PUT97]) show that between 60 and 80 percent of all software efforts spent will be spent after it is delivered to the client for the first myth. Until I get. program "run" I have no way to determine the quality of its reality to assess one of the mechanisms of effective quality assurance programs can be applied in creating a formal draft technical review reviews software (described in Chapter 8). A quality filter, "which found more effective than testing for finding certain classes of software defects.

crises of the software.

Many industry observers (including this writer) have characterized the problems of software development as a "crisis." More than a few books (eg, [GLA97] [FLO97], [YOU98a]) said that the impact of some of the most spectacular software failures over the past decade has occurred. However, the great successes achieved by the software industry, many question whether the term software crisis is still relevant. Robert Glass, author of several books on software failures, are representative of those who have a change of heart. He claims [GLA98]. I see my failure stories and see exception reporting, spectacular failures in the midst of many successes, a cup that [now] almost complete "It is true that software people more often than they succeed. This is also true that software crisis predicted 30 years ago that never seemed to materializ What we really have anything to else .. The crisis of the term is defined in Webster's dictionary as, but in terms of overall software quality and speed of computer systems, base and products develop "a turning point in the course of something important or decisive stage time or event" No ". turning point, "not" time critical "only slow, evolutionary change, punctuated by explosive technological changes in discipline related to software. The crisis of the word has a different definition:" turning point in the course of a disease when it becomes clear whether the patient will live or die. "This definition can give us a clue about the nature of the real problems that plague software development that we really could be better characterized. as a chronic pain affliction.2 word is defined as "But nothing causes pain or distress." definition of chronic family name is the key to our argument "length long or often repeated, continuing indefinitely." It is more correct problems in the software industry must endure as a chronic pain described as a crisis.

software applications::

software Software application for every situation where a number of process steps (eg algorithm) were identified (with the exception of this rule in the expert system software and neural network software). Content and identify important factors that the nature of the software. Content refers to the meaning and form of input and output data. Using a variety of business applications such as entering highly structured data (database) and presentation of "reports." The software that controls the machine (eg, digital program-controlled) take a discrete data elements and structure of the limited production of individual machine commands in rapid succession.

 Information about determining the predictability of process information and deadlines. Engineering program receives the data analysis algorithm (s) continued to meet to determine and produce details of the report or graphic format. Such programs are defined. Multi User System operating system, by contrast, takes an input variable and arbitrary deadlines and implementation of algorithms can be interrupted external circumstances, and production, which varies depending on the environment and time. Using these properties are undefined. It's a little harder important general categories of software development to be done. With the increasing complexity of software, different compartments disappeared. 

Variety of possible applications:

 1> System Software: Following in the software of the wide range of applications too. System software is a set of programs written for other service programs. Some systems software (such as compilers, editors and file management utilities) complex process, but some data structures. Other areas of application systems (such as operating system components, drivers, telecommunications processors) process largely uncertain data. Anyway, in terms of systems software is to simultaneously work of serious interaction with computers, the heavy use by multiple users, characterized in that require planning, sharing resources and complex process of managing complex data structures and various external interfaces.

 2> Real-time software. The software monitors, analyzes, manages the actual events as they occur is called real time. Elements of real-time software includes data-gathering component collects and formats the information from the environment, the analysis component that converts the information in accordance with the requirements of programs, management and execution component that responds to the environment and monitoring component coordinates all the components in real-time response (typically within 1 ms to 1 second) can be stored. 

3> Business Software. Business information processing is the largest part of the application software. Discrete "systems (such as payroll, accounts receivable / payable, inventory) in the management information system (MIS), software that allows one or more large databases of business information mail programs in the restructuring of the existing data in a form. The business' or management decisions addition to traditional data processing applications. business applications software includes interactive computer (eg pointof-sale transaction processing).

 4> engineering and scientific applications engineering and science programs. is characterized by "crunching" algorithms. scale ranging from astronomy Volcanology, automotive stress analysis shuttle orbital dynamics and molecular biology to computer-aided manufacturing but various modern applications in technical and scientific areas of the traditional calculation algorithms .. Computer-aided design, simulation and other interactive programs begin real time performance, even taking system software.

 5> Embedded Software Intellectual products. has become commonplace. in almost all consumer and industrial markets embedded software in ROM and is used to control products and systems for consumer and industrial markets. embedded software very limited and esoteric functions (eg keyboard control for microwave ovens) or perform vital functions and control (eg, digital motor control, such as fuel control panel, and braking) Personal Computer led .. Private market computer software in the past two decades, word processing, spreadsheets, computer graphics, multimedia, entertainment, database management, personal and business finance programs, external networks, and database access to only a few hundred programs .. Web-based program. Websites refuge browser software, including executable instructions (eg ., CGI, HTML, Perl or Java) and data ..