System Requirements and initial questions

Requirements and questions EXTENDED2
Requirements are like water. They're easier to build on when they're frozen.
The client needs a software solution which has well defined set of features.

-------------------------------------------
Why Have Official Requirements?
------------------------------------------
An explicit set of requirements is important for several reasons.
Explicit requirements help to ensure that the user rather than the programmer drives the system's functionality. If the requirements are explicit, the user can review them and agree to them. If they're not, the programmer, developer or designer usually ends up making requirements decisions during coding. Explicit requirements keep you from guessing what the user, i.e client wants.

Explicit requirements also help to avoid arguments. If you have a disagreement with another programmer, designer or customer, about what the web system, program or applications is supposed to do, you can resolve it by looking at the written requirements, specifications and design guidelines.

Essential and optional features
*** MoSCoW priority ***********************************
• Must have
• Should have
• Could have
• Won't have

Developing software to meet functional requirements with acceptable quality, on planned schedule, and within budget is a target pursued by every software development organization.
Answers to these questions can sometimes discover unrealistic business targets coupled with too low budget and or poor planing.

NASA identified ten fundamental quality characteristics of software requirements specifications that are closely related to indicators of specification strengths and weaknesses, which are referred to as “quality indicators.” A quality requirements specification must be:
• Complete
• Consistent
• Accurate
• Modifiable
• Ranked
• Testable
• Traceable
• Unambiguous
• Verifiable
• Valid

-------------------
Pay ATTENTION
-------------------
Data from numerous organizations indicates that on large projects an error in requirements detected during the architecture stage is typically 3 times as expensive to correct as it would be if it were detected during the requirements stage.
If detected during coding, it's 5-10 times as expensive; during system test, 10 times;
and post-release, a whopping 10-100 times as expensive as it would be if it were detected during requirements development.
On smaller projects with lower administrative costs, the multiplier post-release is closer to 5-10 than 100 (Boehm and Turner 2004). In either case, it isn't money and precious time you'd want to waste.

1. Who will be creating and writing the "initial product specifications, features and requirements":
a) Developer/Coder?
b) Customer?
c) Product manager - Neutral Tester?

2. Who will be reading/validating these specifications:
a) Product manager? Coder?
b) Customer? Tester? User?

3. Who will be maintaining these specifications (this can often be the hardest part)?
a) Product manager? Customer?
b) Coder?
c) Tester? User?

4. What is the purpose of the specifications? Is it to ensure that the software works as desired? Are specifications intended to fully cover all of the possible use cases, or only a cross-section? Are they "start-to-finish" tests, i.e., a full business use case, or are they scenarios?
Do we have test cases data sets (input / desired output) upon the future software will perform?
Is customer providing a real examples of a formal use cases, with real production data?

5. Will customer also provide a Constant Product Testing and inspections in order to find out if the product features meet all his requirements and test specifications?
Is there mandated list of predefined tests and operational inspections prior to every production activity?
Do inspections must pass before the software is allowed to enter further nonfunctional/quality tests?

COCOMO questions
7. Software Precedentedness questions
7.1 Organizational understanding of product objectives / business logic / customer needs
a.General
b.Considerable
c.Thorough

7.2 Experience in working with and/or developing related software systems
a.Moderate
b.Considerable
c.Extensive

7.3 Concurrent development of associated new features and operational procedures
a.Extensive
b.Moderate
c.Some

8. Development Flexibility questions
8.1 Need for software conformance with pre-established requirements
a.Full
b.Considerable
c.Basic

8.2 Need for software conformance with external interface specifications
a.Full
b.Considerable
c.Basic

8.3 Premium on early completion
a.High
b.Medium
c.Low


Use the list as a sanity check at construction time to determine how solid the ground that you're standing on is—where you are on the requirements Richter scale.
Not all of the checklist questions will apply to your project. If you're working on an informal project, you'll find some that you don't even need to think about. You'll find others that you need to think about but don't need to answer formally. If you're working on a large, formal project, however, you may need to consider every one.
----------------------------------------
9. Specific Functional Requirements
----------------------------------------
Are all the inputs to the system specified, including their source, accuracy, range of values, and frequency?
Are all the outputs from the system specified, including their destination, accuracy, range of values, frequency, and format?
Are all output formats specified for Web pages, reports, and so on?
Are all data interfaces specified?
Are all the external communication interfaces specified, including handshaking, error-checking, and communication protocols?
Are all the tasks the user wants to perform specified?
Is the data used in each task and the data resulting from each task specified?
Are all constrained data properties well specified?
Are all system and subsystem dependencies well specified?


So, so far, I believe development is far more a complex process than just writing code. And coding is far more complex that just writing an executable set of instructions for a machine (Description of a solution, remember?) Thus, I proclaim that coding is not the same as developing.
“The Fundamental Rules” of Software Engineering

1) Is there a system architectural design with well-defined software-components (subsystems, modules), their interfaces, data exchange protocols, integration procedures/tests?

2) Is there software design before coding?

---------------------------
3) Requirements Checklists
---------------------------
Requirements checklists should address and identify:
- is there duplicated information?
- missing information
- is something vague or unclear?
- Use cases set and scenarios will help gathering, organizing and verifying requirements.
- review possible software reuse - feedback from previous work efforts

-------------------------------
4) GENERAL SPECIFICATIONS
-------------------------------
In this early stage it is clear :
- what are the files in the system repository, and what is their record structure
- what is desired behaviour of the software modules and objects
- feature specification list
- test data and test scenarios / input and desired output
Customer must be aware that in general lines, the software requirements should be set in stone before Development CYCLUS begins, in order not to wasted work put into a design and development based on incorrect requirements.
- what must be done in order to collect ALL input data
- the customer should provide SOME input data examples
- what must be done in order to process input data files into desired output behaviour and data.
- Make sure everyone knows the cost of requirements changes Clients get excited when they think of a new feature.
Who has requirements authority?
Someone has to define the requirements and get them approved by the necessary par-
ties (clients or end-user advocate).
How often will requirements and designs be reviewed, and how will adjustments be decided?

6) Startup Conditions
Create clear Startup Conditions Checklist - Explain what is missing for the project kick-off! What is missing for the start?


7) AMBIGUITIES ELIMINATION
Specifications are almost always incomplete and fraught with ambiguities. Constant contact with the customer is required to obtain the correct requirements. Without this communication, the developers tend to make incorrect assumptions about what the customer wants [6].

8) Fluctuating and conflicting requirements is a major phenomenon that greatly reduces software development productivity and quality [5]. Requirements will appear to fluctuate when the development team lacks application knowledge and performs an incomplete analysis of the requirements [5].

9) Communication and coordination collapse is a major phenomenon that greatly reduces software productivity and quality [5].

10) Is there Development roadmap?
Testing while coding is the fundamental idea behind the iterative software growth stages. The earlier problems are discovered, the less the overall cost will be [7].
- Planning of the iterative software growth stages,
- tests case examination scenario, with input parameters and desired output data must be done upfront, before the coding starts.
- specify valid test case
- create a sequence of test instances in a batch,
- MILESTONE development planning, starting with very simple but functional code
- monitor test case execution in a Log file, and report success, failure, and a type of error or warning during and after the execution of the code

---------------------------------------------------------------------------------------------------
PLANNING AND BIG PICTURE ORIENTATION: Where you're, and where are you going?
---------------------------------------------------------------------------------------------------
★ Programming without an overall architecture or design in mind is like exploring a cave with only a flash-light: You don't know where you've been, you don't know where you're going, and you don't know quite where you are.
- Danny Thorpe, former Chief Architect of the Delphi programming language


11) Specification mistakes often occur when designers do not have sufficient application specific-domain knowledge to interpret the customer’s intentions from his initial requirements document [5].

12) Reviews of non-technical documents (e.g., requirements specification, user manual) are more effective if the customer is involved [10].

15) Extreme time pressure leads to a faster rate at which errors are made, which leads to a further delay in the completion date [9]. Extreme time pressure leads to decreased productivity [7].

18) Always test everything. Tests reveal errors in the code. The better a test is prepared for, the higher amount of detected errors.

19) Software inspections find a high percentage of errors early in the development life cycle [13]. Talk to real end-users and not only to customer to verify and approve the prototype.


20) Are formal change request procedures defined?
Changing requirements are inevitable. Anticipating change with open architectures, adaptable designs, and flexible planning can help to mediate some of the ill effects of these changes [6].

50) Decisions made in the upstream portion of the software development process (requirements and design) impact productivity, quality, and costs throughout the life cycle more than the other portions [5].


40) Rework is usually due to customer requirements, product flaws, and communication breakdown between project members. Improving the process to reduce rework can be done by using prototyping and evolutionary development and by using formal specification methods, modern programming practices, and inspections. Reducing rework increases productivity [13].

27) Design for change/variability software maintenance.

30) Successful software is designed by people who understand the application of the software (e.g., a well-designed missile control program was designed by someone who understood missiles) [8].

36) Motivation is increased through monetary incentives (profit sharing, pay for performance, merit pay, work measurement with incentives, and morale measurement), creating a positive frame of mind at work (employee involvement in wellness programs and creating fun at work), encouraging a feeling of commitment and responsibility (worker participation in decision-making, getting employees to think like owners, self-managing work teams, commitment to productivity breakthroughs, and providing an environment with more freedom and less restrictions), and increasing schedule pressure (using visible milestones and setting individual goals.) Increased motivation leads to increased productivity which reduces cycle time [13].

37) Improving the work environment is done by making ergonomic considerations, giving employees enclosed offices to reduce background noise and interruptions, and giving employees access to required resources, such as computers, software tools, support staff, and information. Improving the work environment leads to increased productivity, which reduces cycle time [13].

39) Improving the software development process can be done by formalizing the process, controlling quality, and taking advantage of automated tools. [13].

41) REDUCING OVERALL COMPLEXITY can be achieved. Product complexity can be reduced by reducing code complexity, design complexity, cognitive complexity, test complexity, and management complexity.
• Design complexity reduction is obtained by using object-oriented design techniques
• Code complexity reduction is achieved by using modularization and object-oriented programming techniques
• Cognitive complexity reduction is achieved by modularization, multiple levels of abstraction, simulation, and prototyping
• Test complexity can be reduced by using testing tools, building the product with testing in mind, and testing for the type of environment a product will be used in.
• Management complexity can be reduced by using project management planning tools and methods.
Reducing design, code, cognitive, test and management complexity reduces product complexity which increases productivity [13]

45) Tasks can be eliminated or simplified by using automation of tasks (e.g., code generators, automated testing) and eliminating non-value added activities and low-priority tasks. This leads to increased productivity [13].

46) Risk can be reduced by using risk management techniques. Reducing risk leads to increased productivity [13].

47) Nine ways to reduce cycle time are: increase productivity, reduce rework, maximize software reuse, reduce product complexity, eliminate or simplify tasks, maximize task concurrency, reduce undiscovered work, reduce risk, and use process models aimed at cycle time reduction [13].

48) Productivity is increased by increasing motivation, improving the work environment, getting the best people for the job, improving the process, and maximizing reuse [13].

54) CONSTANT COMMUNICATION
Coordinating understanding of an application and its environment context requires constant communication between customers and developers. It should be facilitated by project and product managers. They should have some authority and not only the responsibility [5].

58) TRULY EXCEPTIONAL SOFTWARE ARCHITECTS ARE RARE RESOURCE
Truly exceptional software architects, developers & designers that are extremely familiar with the application domain, skilled at communicating their technical vision to other project members, possess an exceptional ability to map between the behaviour required of the application system and the computational structures that implement the behaviour, and are recognized as the “intellectual core” of the project are a scarce resource [5].

59) New requirements frequently emerge during development since they could not be identified until portions of the system had been designed or implemented [5].

60) Besides a developer’s ability to design and implement programs, his skills in resolving conflicting requirements, negotiating with the customer, ensuring that the development staff shares a consistent understanding of the design, and providing communications between two contending groups are crucial to project performance [5].

61) Undiscovered work (work that was not considered in initial planning estimates) can be reduced by using formal methods, analysis of PERT sizing metrics, the Spiral life cycle model, and prototyping. Think upfront proactively. Reducing undiscovered work leads to increased productivity [13].

63) Inspections should be thought of as part of the development process, and time must be set aside accordingly. Once this is done, inspections can have a significant improvement in the development organization’s ability to meet internal schedules. Proper use of inspections can even shorten life cycle [13].

65) Participants in the inspection team get a high degree of product knowledge, which leads to higher productivity [13].

66) Slower programmers show a great deal of improvement when using inspections [13].

69) Employers often limit the number of hours employees can work, resulting in further pressure to finish a project as quickly as possible [6].

70) The customer often changes deadlines to be earlier than originally agreed-upon, requiring negotiation with the customer for either allowing some deliverables to be delivered at the earlier date, with the rest being delivered later, or dropping some deliverables or requirements altogether [6].

71) Code comments and documentation are often produced at the end of a project, creating major problems when a team member is lost at short notice, leaving others to continue their work. This can be alleviated by having quality auditors require inspections at very short notice [6].

CRAB EFFECT - Regression tests
73) Often the software used for the production is upgraded to a new version, and despite claims that it is fully backward-compatible and won’t affect their work, it usually introduces new problems. And some stable old features are broken. [6].

76) Matching the tasks to the skills and motivation of the people available increases productivity [2].

77) Employee motivation is the strongest influence of productivity [2].

78) Above a certain threshold, work conditions are not a powerful motivator, but below that threshold, they are a powerful de-motivator [2].

79) The training of new employees is usually done by the “old-timers,” which results in a reduced level of productivity on the “old-timer’s” part. Specifically, on the average, each new employee consumes in training overhead 20% of an experienced employee’s time for the duration of the training or assimilation period [1]. The average assimilation delay, the period of time it takes for a new employee to become fully productive, is 80 days [1].

81) As schedule pressure increases, quality assurance activities (especially walk-throughs and inspections) are often relaxed or suspended altogether [1].

82) In the absence of schedule pressure, a full-time employee allocates, on average, 60% of his working hours to the project (the rest is slack time: reading mail, personal activities, non-project related company business, etc.) [1].

83) Under schedule pressure, people tend to increase their percentage of working hours spent on the project by as much as 100%, due to spending less time on off-project activities, such as personal business and non-project communication, and/or working overtime [1].

85) The two “task -type” variables that have the greatest impact on programmer productivity are the programming language and the quality of external documentation [1].

90) Non-functional requirements
-----------------------------
QUALITY REQUIREMENTS
-----------------------------
Whatever the approach to software development may be, the final software must satisfy some fundamental quality requirements. The following software properties are among the most relevant:

* Efficiency/performance: the amount of system resources a program consumes (processor time, memory space, slow devices such as disks, network bandwidth and to some extent even user interaction): the less, the better. This also includes correct disposal of some resources, such as cleaning up temporary files and lack of memory leaks.

* Reliability: how often the results of a program are correct. This depends on conceptual correctness of algorithms, and minimization of programming mistakes, such as mistakes in resource management (e.g., buffer overflows and race conditions) and logic errors (such as division by zero or off-by-one errors).

* Robustness: how well software solution reacts to invalid input problems not due to programmer error. This includes situations such as incorrect, inappropriate or corrupt data, unavailability of needed resources such as memory, operating system services and network connections, and user error.

* Usability: the ergonomics of a program: the ease with which a person can use the program for its intended purpose, or in some cases even unanticipated purposes. Such issues can make or break its success even regardless of other issues. This involves a wide range of textual, graphical and sometimes hardware elements that improve the clarity, intuitiveness, cohesiveness and completeness of a program's user interface.

* Portability: the range of computer hardware and operating system platforms on which the source code of a program can be compiled/interpreted and run. This depends on differences in the programming facilities provided by the different platforms, including hardware and operating system resources, expected behaviour of the hardware and operating system, and availability of platform specific compilers (and sometimes libraries) for the language of the source code

* Maintainability: the ease with which a program can be modified by its present or future developers in order to make improvements or customizations, fix bugs and security holes, or adapt it to new environments. Good practices during initial development make the difference in this regard. This quality may not be directly apparent to the end user but it can significantly affect the fate of a program over the long term.

Is the expected response time, from the user's point of view, specified for all necessary operations?
Are other timing considerations specified, such as processing time, datatransfer rate, and system throughput?
Is the level of security specified?
Is the reliability specified, including the consequences of software failure, the vital information that needs to be protected from failure, and the strategy for error detection and recovery?
Are minimum machine memory and free disk space specified upfront?
Is there built-in early warning software alert for exhausting system resources?
Is the maintainability of the system specified, including its ability to adapt to changes in specific functionality, changes in the operating environment, and changes in its interfaces with other software?
Is there the definition of success included? Or failure?
Quality Assurance QA test planning, precedes code crafting, growth and refinement. We must creates a test plan and populate it with test cases from trivial to complicated one with desired results outcome. We should also relate test cases to functional requirements, deploy a test plan, start executing test cases and designate them as successful or failed. We must create the software which generates reports on our test cases.
During the development we should also be able to:
- specify valid test parameters
- create a sequence of test instances in a batch,
- MILESTONE development planning, starting with simple but functional code
- monitor test case execution in a Log file, and report success, failure, and a type of error or warning during and after the execution of the code
- add and to remove particular test cases from the test batch
- do requirements tracking
- track the software growth, mutations and evolution on the roadmap milestones
- do bug reporting and solution tracking

The Milestones and Incremental Development process is not only a great way to map out complex functionality, it's also IMPORTANT to test out critical features before they're launched. During our INCREMENTAL DEVELOPMENT process we can make some changes in the application structure in an effort to better organise bug-tracking, development and feature releases.

----------------------------
99) Requirements Quality
----------------------------
If your requirements aren't good enough, stop design, stop coding, make reclamation, and make them right before you proceed. Sure, it is better to stop than to proceed in wrong direction.

Are the requirements written in the user's language? Do the users think so?
Does each requirement avoid conflicts with other requirements?
Are acceptable tradeoffs between competing attributes specified—for example, between robustness and correctness?
Do the requirements avoid specifying the design?
Are the requirements at a fairly consistent level of detail? Should any requirement be specified in more detail? Should any requirement be specified in less detail?
Are the requirements clear enough to be turned over to an independent group for construction and still be understood? Do the developers think so?
Is each item relevant to the problem and its solution? Can each item be traced to its origin in the problem environment?
Is each requirement testable? Will it be possible for independent testing to determine whether each requirement has been satisfied?
Are all possible changes to the requirements specified, including the likelihood of each change?
Requirements Completeness
Where information isn't available before development begins, are the areas of incompleteness specified?
Are the requirements complete in the sense that if the product satisfies every requirement, it will be acceptable?
Are you comfortable with all the requirements? Have you eliminated requirements that are impossible to implement and included just to appease your customer or your boss?



100) Preventing contractual dispute
In order not to arrive to the situation where the client can claim that we did not deliver what he has asked, the deliverables after each milestone should be payed, re-controlled and inspected by the client or his representative. Do not make grand-finale payment contracts, it is too risky.

The client after each milestone should review the functionalities promised in the contract and cross-examine it against and sign a formal approval and provide a list of remarks or reclamations, which should be addressed in the next development cycle.

Failure reduction is an essential step towards excellence. And each defect, glitch or bug will be addressed in Test driven development.

--------------------------------------------------------------------
101) CHANGE REQUEST - The Myth of Stable Requirements
--------------------------------------------------------------------
Stable requirements are the holy grail of software development.

With stable requirements, a project can proceed from architecture to design to coding to testing in a way that's orderly, predictable, and calm. This is software heaven! You have predictable expenses, and you never have to worry about a feature costing 100 times as much to implement as it would otherwise because your user didn't think of it until you were finished debugging.

102) Did you and your customer found acceptable balance among conflicting requirements, all constraints and stallholder needs?

It's fine to hope that once your client has accepted a requirements document, no changes will be needed. On a typical project, however, the customer can't reliably describe what is needed before the code is written.
The problem isn't that the customers are vague. Just as the more you work with the project, the better you understand it, the more they work with it, the better they understand it. The development process helps customers better understand their own needs, and this is a major source of requirements changes (Curtis, Krasner, and Iscoe 1988; Jones 1998; Wiegers 2003). A plan to follow the requirements rigidly is actually a plan not to respond to your customer.
How much change is typical? Studies at IBM and other companies have found that the average project experiences about a 25 percent change in requirements during development (Boehm 1981, Jones 1994, Jones 2000), which accounts for 70 to 85 percent of the rework on a typical project (Leffingwell 1997, Wiegers 2003).

Make sure everyone knows the cost of requirements changes Clients get excited when they think of a new feature. In their excitement, their blood thins and runs to their medulla oblongata and they become giddy, forgetting all the meetings you had to discuss requirements, the signing ceremony, and the completed requirements document. The easiest way to handle such feature-intoxicated people is to say, "Well, that sounds like a great idea. Since it's not in the requirements document, I'll work up a revised schedule and cost estimate so that you can decide whether you want to do it now or later." The words "schedule" and "cost" are more sobering than coffee and a cold shower, and many "must haves" will quickly turn into "nice to haves." in the MoSCoW list.


103) Historically there are four types of requirement artifacts in functional specification:
-1 the text requirements
-2 the use case, and business/domain glossary
-3 the process-flow diagram
-4 the screen-shots with GUI elements and mockup content
-5 the simulation is actually new type of requirement, the 5th type of specification artifact, which has entered recently among the product specification artifacts. Only simulation can give the business customer real awareness that product specification correctly defines all his needs.


-------------------------------
103) The requirements pyramid
-------------------------------
✤ Needs :: contains high-level requirements (vague user desires and wishes, prepared by Marketing department, contains high-level customer requirements and vague desires)
✤ Use cases / prepared by Business Analysts, and are written on the basis of customer needs and desires.
✤ Features :: while needs come from the end user, the features are formulated by business analysts and customer's marketing department.
✤ Scenarios :: Any situation that may occur in production, or any sequence of events which may occur when the end user is in interaction with the software system
✤ Use cases :: Use Case is one specific scenario, which are written by business analysts on the basis of customer needs and requirements.
✤ Input data sets :: based on the use case document and delivered by the customer, it is also useful to have up front Input/corresponding Output data sets for testing
✤ Test Cases :: engineers prepare test cases, based on the use case document
✤ supplementary requirements
✤ The User interface proposal :: GUI, or CLI, or NUI
✤ Technical details of hardware or software
✤ Glossary of specific terms
✤ The User Manual proposal

walk-through & use cases
------------------------------------------------------

Walk-through in one use scenario of a software application or a system is one particular Use case scenario, of immense number of possible scenarios.

Use cases are generally prepared by Business Analysts, to better understand the functionality of the application, generally use case contains preconditions, field validations, event lists, postconditions, flow graph, prototype.
Based on the use case document test engineers prepare test cases.
Use Case are the various scenario, which are written on the basis of customer/supplier requirements.
While Test Case are the documented steps, which are written by software engineers on the basis of use cases.
Use cases are prepared from the Functionality requirement document.

---------------
Bibliography
---------------
1. Abdel-Hamid, T. and S.E. Madnick, Software Project Dynamics: an Integrated Approach. 1991, Upper Saddle River, NJ: Prentice-Hall, Inc.
2. Boehm, B.W., Software Engineering Economics. 1981, Upper Saddle River, NJ: Prentice Hall, Inc.
3. Brooks, F.P., The Mythical Man-Month: Essays on Software Engineering. 2 ed. 1995: Addison-Wesley. 336.
4. Bryan, G.E., Not All Programmers are Created Equal, in Software Engineering Project Management, R.H. Thayer, Editor. 1997, IEEE Computer Society: Los Alamitos, CA. p. 346-355.
5. Curtis, B., H. Krasner, and N. Iscoe, A Field Study of the Software Design Process for Large Systems. Communications of the ACM, 1988. 31(11): p. 1268-1287.
6. Dawson, R., Twenty Dirty Tricks to Train Software Engineers, in Proceedings of the 22nd International Conference on Software Engineering. 2000, ACM. p. 209-218.
7. Drappa, A. and J. Ludewig, Simulation in Software Engineering Training, in Proceedings of the 22nd Internation Conference on Software Engineering. 2000, ACM. p. 199-208.
8. Humphrey, W.S., Managing the Software Process. 1990: Addison-Wesley.
9. Levary, R.R. and C.Y. Lin, Modelling the Software Development Process Using an Expert Simulation System Having Fuzzy Logic. Software -- Practice and Experience, 1991. 21(2): p. 133-148.
10. Pressman, R.S., Software Engineering -- A Practitioner's Approach. 4 ed. 1997, New York, NY: McGraw-Hill.
11. Sackman, H., W.J. Erikson, and E.E. Grant, Exploratory Experimental Studies Comparing Online and Offline Programming Performance. Communications of the ACM, 1968. 11(1): p. 3-11.
12. Tang, J.C., Findings from Observational Studies of Collaborative Work, in Readings in Groupware and Computer-Supported Cooperative Work, R.M. Baecker, Editor. 1990, Morgan Kaufmann: San Mateo, CA. p. 251-259.
13. Tvedt, J.D., An Extensible Model for Evaluating the Impact of Process Improvements on Software Development Cycle Time. 1996, Ph.D. Dissertation, Arizona State University.
14. Weller, E.F., Lessons from Three Years of Inspection Data. IEEE Software, 1993. 10(5): p. 38-45.
Introduction
As software becomes increasingly important in systems that perform complex and critical functions, e.g., military defence, nuclear reactors, so too have the risks and impacts of software-caused failures. There is now general accord on the need to increase software reliability and quality by eliminating errors created during software development. Industry and academic institutions have responded to this need by improving developmental methods in the technology known as software engineering and by employing systematic checks to detect software errors during and in parallel with the developmental process.
Many organizations make the reduction of defects their first quality goal. Therefore, detecting and correcting a serious software defect would entail recalling hundreds of thousands of products. In the past 35 years, hundreds of research papers have been published in the areas of software quality, software engineering development process, software reliability modelling, software independent verification and validation (IV&V) and software fault tolerance. Software engineering is evolving from an art to a practical engineering discipline (Lyu 1996).
A large number of analytical models have been proposed and studied over the last two decades for assessing the quality of a software system. Each model must make some assumptions about the development process and test environment. The environment can change depending on the software application, the lifecycle development process as well as the capabilities of the engineering design team
(Malaiya 1990). Therefore, it is important for software users and practitioners to be familiar with all the relevant models in order to make informed decisions about the quality of any software product.
This chapter provides the basic concepts of software engineering assessment including software lifecycle, software development process and its applications, software verification and validation, and data collection and analysis.
Whether starting from scratch or redesigning, is all about planning and organization. Think long-term but focus on short-term -- and never lose sight of your customer.
The Core Process: A comprehensive, modifiable plan. A starting point for all kinds of teams and all kinds of budgets.