Post by hari on Oct 30, 2010 15:40:26 GMT 5.5
UNIT – 1.
Introductions to software engineering
I EEE defines software engineering as the systematic approach to the development, operation maintenance and retirements of software.
The term software defines as computer programs, procedure rule and possibility of an associated document and data pertaining to the operation of a computer system.
Standard definition of software engineering:
Software engineering is the technical and managerial discipline concerned with systematic production and maintenance of software products that are developed and modified on time and within cost estimates.
Goals of software engineering:
The primary goal of software engineering to improve quality of software products and to increase the productivity and to increase the productivity and job satisfaction of software engineering.
Software is intangible no color, no volume, no order, no properties software engineer
create the model of software.
Software engineering units called modules software models have both control and data interface.
Some definitions:
Software engineering differs from traditional computer program.
Software is concerned with managerial issues.
Software is additionally concerns with issues, analysis, design, verification and testing documentation, Software maintenance and project management.
Software concepts applicable only for projects for long duration.
Computer Software denoted as Software products.
Documentation explains the characteristics of a document.
Software concern with systematic development and maintenance of documentation.
Software quality is a primary concern of Software engineers.
A software product satisfies user needs.
Software reliability:
It is the ability of the program to perform a required function under stated condition for a stated Period of time.
Software products must be clearly written and easy to understand.
Software products must be efficient only appropriate application.
Software product must be cost efficient in development maintenance and in use.
Development and maintenance increase the efficiency and reliability of software Products.
Some size factors:
In this the levels of effort devoted to Software development and maintenance.
• Total effort devoted to software.
• Distribution of effort.
• Project size categories.
• How programmers spend their time.
Total effort devoted to software:
• Demand for high quality Software .
• Goal of Software engineering.
• Diagram specifies changing ratio expenditure for then
hardware and Software overtime.
In 1960: 80% = hardware cost.
20% = Software cost.
In 1980: 80% = Software cost.
20% = hardware cost.
Changing hardware, software cost ratio:
Distribution of effort:
Life plan of Software product 1-3 years in development 5 to 15 years in maintenance.
Software maintenance involves 3 types of achieves:
Enhancing the capabilities of product.
Adopting the product to new processing environment.
Connecting bugg distribution of maintenances effort.
60% = enhancement.
20% = adaption.
20% = connection.
During development level of Software the distribution effort:
40% = analysis and design.
20% = implementation, debugging and unit test.
40% = integration and acceptance.
Project size categories:
Trivial project 1 programmers, few days, and 500 statements.
Small project - 1 programmer, 1 to 6 months, 1000 to 2000 lines.
Medium size project - 2 to5 programmers, 1-2 years, 10000- 50000 lines of source code.
Large project- 5 to 20 programmers, 2 - 3 years, 50000 - 100000 source statements.
Very large project- 100 – 1000 programmers, 4-5 years, 1 million source instruction.
Extremely large projects-2000-5000, up to 10 years, 1 million - 10 million source code.
How programmers spend the time:
Writing program – 13%.
Reading program and manual – 16 %.
Job communication – 32 %.
Personal – 13 %.
Miscellaneous – 15 %.
Training – 6 %.
Mail – 5 %.
Distribution of effort of two software products:
Quality and productivity factors:
Development and maintenance of software:
Product to be more complex, it is difficult to understand of systematic activities.
Development and maintenance of high quality software product requires technical and managerial
Skill some Factors that quality and productivity listed in following table.
1. Individual ability.
2. Team communication.
3. Product complexity.
4. Appropriate notations.
5. Systematic approaches.
6. Change control.
7. Level of technology.
8. Level of reliability.
9. Problem understanding.
10. Available time.
11. Required skills.
12. Facilities and resources.
13. Adequacy of training.
14. Management skills.
15. Rising expectations.
16. Appropriate goals.
17. Other factors.
Individual ability:
General competence of the individual.
Familiarity of the individual with particular application area
Lack of familiarity with the application area can result in low productivity and poor quality. Small
And medium size project extends sensitive to the ability of the individual programmer.
Factors that influence quality and productivity:
Individual ability.
Team communication.
Required skills.
Change control.
Team communication:
Programming has traditionally has been regarded as an individual and private activity Increased required among the programmers, managers and customers
Product complexity:
There is generally acknowledged levels of product complexity.
• Application programs.
• Utility programs.
• System level programs.
Application programs – FORTAN, COBOL.
Utility programs – compilers, assemblers.
System level programs - editor.
Develop and maintenance a software product nonlinear function of product size and complexity.
Appropriate notation:
Good notations clarify the relationship and instruction of interest while poor notation complicate
and interface with good practice.
Systematic approaches:
Evaluation of software engineering it is often not clear which of the various approaches to Software development should used in which situations.
Change control:
Requirements can also change due to poor understanding the problem. Notation and procedures. To that provide the ability to track and asses the impact of proposed change.
Level of technology:
It is utilized on a software project accounts for such factors as the programming language and software tools. Stability and availability of the machine environment on productivity and quality.
Level of reliability:
Every software product must posses a basic level of reliability. Both human and machine resource is required to obtain increased reliability.
Problem understanding:
Several factors that contribute to the lack of understanding. A software engineers have no Oppurnitity investigate the users problem automated solution changes the nature of problem.
Available time:
Programmer’s productivity is also sensitive to the calendar time available for project completion. The resulting programmer’s productivity and software quality are the sensitive functions of the time available for product, development and production. Required skills:
software engineer requires a vast range of skills. Extracting the information from customers in. Order establish user needs demands good knowledge about the about the application area. Requirements and design are different problem solving skills. External document require good skills. Software engineer must be technically competent and posses sufficient social skills to the
With managers, customers and other engineers.
Adequacy of training:
Most programmers have been trained as computer scientist and industries have traditionally sought software engineers, accountants (or) mathematicians.
Software engineering concern with analysis, designing, construction, testing, verifying,
Documenting. Operating and maintenance of software products.
Facilities and resources:
software project managers must be effective in dealing with the factors and frustrate.
programmers if they are maintain high product quality, high programmer, productivity and high job satisfaction.
Management skills:
Many organization offer project management training to software engineers to prepare for Project management tasks, this is not always successful. Low needs of means software people and need for good skills in managers.
Appropriate goals:
The primary goal of software engineers is development of software products that are appropriate for their intended use.
Rising expectations:
There are interrelated aspects to rising expectation first is the concern for how much
Functioning performance can be provided by given amount of development effort. It is the issue of fundamental limitations of software technology, systematic techniques to
Develop and maintain software products reserves improved product quality.
Other factors:
Many factors that influence programmer, productivity, including familiarity with a user to, Stability of computing system used to develop modify the software.
Managerial issues:
Technical and managerial activities are equally important to the success of the software project, managers control the resources and the environment in which technical activities.
Other management responsibility include develop business plan, develop market strategy
and training the employees.
Project management includes method of organizing and maintaining a project cost
Estimation techniques, Resource allocation policy.
Important management problems are:
• Plan for software engineering projects.
• Plan and techniques for the selection of project managers poor.
• Accountability of many software engineering projects is poor.
• Estimate the resource required to accomplish a development is poor.
• Students and techniques for measuring the quality of performance.
• Decision rules not available.
Some of the methods mentioned for solving this problem were,
• Educate and train top management, project managers and software developers.
• Enforce the use of standards
• Analysis data from software project.
• Define the objectives.
• Define the quality
• Establish success priority criteria.
• Allow for categories.
• Select project managers based on the ability to manage software projects.
Software projects management is programmers and managers tend to have differing
perceptions. Professional managers do not have the technical knowledge to deal with
managerial problem is software engineering.
Problem solution originated by managers often perceived by the programmers as fixing minor
Aspects of the situations, technical and managerial issues are equally important in software
Engineering improvements in management techniques not kept face with advances in technology.
Similarly problems perceived by programmers are often regarded as significant by the managers.
Planning a software project:
Introduction:
Careful planning is required for both the development process and the work phase is to clarify
Goals needs and constraints.
A software product becomes well understood as it progresses through analysis, design
and implementation.
Defining the problem:
• Develop a definitive statement of the problem to be solved .Include a description of the
present situations, problem constraints and a statement of the goals to be achieved.
• Justified a computerized solution strategy for the problem.
• Identify the functions to be provided by and the constraints on the hardware subsystem the software subsystem and the people subsystem.
• Determine system level goals and requirements for the development process and the work products.
• Establish high-level acceptance criteria for the systems.
Planning a software project:
• The step is planning a software project is to prepare is the customer’s terminology. A concise
Statement of the problem to be solved and the constraints that exist for its solution.
• Problem definition requires a through understanding of the problem domain and the problem environment techniques for gaining this knowledge include customer interview observation of problem tasks and actual performance of the tasks by the planner.
• The second step in planning a software project is to determine the appropriateness of a computerized solution. In addition to being cost effective a computerized system must be
Socially and politically acceptable.
• computing system consist of people subsystems, hardware subsystems, and software
subsystems
Plus the interconnections among subsystem.
• The function to be performed by each major subsystems must be identified the in tractions
Among Subsystems must be established, and development and operational constraints
Must be determined for each major subsystem.
Goals and requirements:
Goals applied to both the development process and the work products and goals. Can be
Either qualitative (or) quantitative.
A quality process goal:
The development process should enhance the professional skill of quality assurance
Personnel.
A quantity process goal:
The system should be delivered with in 12 months.
A quality product goal:
The system should make user’s jobs more interesting.
A quantitative product goal:
The system should produce the cost of a transaction by 25 percent.
• Some goals apply to every project and every product.
• Every software product should be useful, reliable, understandable and cost effective. Requirements specify capabilities that a system must provides in order to solve a Problem. Requirements include functional requirements performance requirements and Requirements for the hardware, firmware,. Software and user interfaces.
Qualitative requirements such as,
• Accuracy shall be sufficient to support mission.
• System shall provide real-time response
• System shall make efficient use of primary memory.
• System shall be 99 % reliable.
High level goals and requirements can often be expressed in terms of quality attributes that
the system should posses.
Software quality characteristic tree:
Glossary of quality attributes:
Portability:
The case with which software can be transferred from one computer system (or)
Environment to another.
Reliability:
The ability of program to perform required functions under stated condition for a stated Period of time.
Efficiency:
The extent to which software perform its intended functions with a minimum consumption of computing resources.
Accuracy:
• A qualitative assessment of freedom from error.
• A quantitative measures of the magnitude of error preferably expreesed as a function of the relative error.
Error:
The discrepancy between a computed value (or) condition and the true specified (or) theoretically correct value (or) condition.
Robustness:
The extent to which software can continue to operate correctly despite the introduction of invalid inputs.
Correctness:
• The extend to which software is free from design defects and from coding defects that is fault free.
• The extend which software meets specified requirements.
• The extend which software meets user expectations.
Some factors to consider in project planning:
• Estimation techniques to be used accuracy required.
• Life cycle model, control functions and reviews.
• Organizational structure.
• Level of formality in specifications, test plans etc.
• Level of configuration management required.
• Level of quality assurance required.
• Level of verification and validation.
• Follow on maintenance responsibilities.
• Tools to be developed and used.
• Personnel recruitment and training.
Some factors to consider in setting project goals:
• New capabilities to be provided.
• Old capabilities to be preserved /enhanced.
• Level of user sophistication.
• Efficiency requirements.
• Reliability requirements.
• Likely modifications.
• Early subsets and implementation priorities.
• Portability requirements.
• Security concerns.
Developing a solution strategy:
• One way of avoiding this problem is to first develop a solution strategy. A solution strategy is not a detailed solution plan, but rather a general statement concerning the nature of?
Possible solution.
• A solution should account for all external factors that are visible to the product users and a strategy should be phrased to permit alternative approaches to product design.
• Several strategies should be considered before one is adopted, however one or more solution strategies must be chosen by the planners in order to perform feasibility
Studies.
• The selected strategy provides a frame work for design and implementation of the software product.
• Solution strategies should be generated without regard for feasibility because it is not possible for humans to be both creative and critical at the same time.
• The strategy is a composite of ideas from several different approaches and the best solution strategy may be become apparent only after all the obvious solutions have been enumerated.
• The feasibility of each proposed solution strategy established by constraints.
• Constraints prescribe the boundaries of the solution space.
• Feasibility analysis determines whether a proposed strategy is within those boundaries, a solution strategy is feasible if the project goals and requirements can be satisfied within the constraints of available time, resources and technology using that strategy.
• Techniques for determining the Feasibility of a solution strategy include case studies, worst case analysis, simulation and construction of prototypes.
• Prototypes implementation usually has limited functionlly, low reliability and poor performance characteristics.
• It is extremely important to document the reasons for rejecting other strategies.
• A solution strategy should include a priority list of product features; there are several important reasons for stating product priorities.
• It is essential that high-level guidance be available to indicate the priorities of essential features, less important features. Product priorities are also useful to indicate the manner in which capabilities can be developed and phased into an evolving system.
• Many software engineers advocate development of systems as a series of successive enhancements to a kernel system.
Planning the development process:
• Planning the software development process involves several important considerations. The first considerations are to define a product life-cycle model. The software life
Cycle encompasses all activities required to define, develop, test, deliver, operate and
maintain a software product.
• It is important to define a life-cycle model for each software project because the model provides basics for categoring and controlling the various activities required to develop and maintain a software product.
• A life-cycle model that is understood and accepted by all concerned parties improves project communication and enhanced project manageability, resource allocation, cost control, and product quality.
The phased life-cycle model:
• Each phase requires well-defined input information, utilizes well-defined processes, and result in well-defined products.
• Resources are required to complete the processes in each phase and each phase is accomplished through the application of explicit methods, tools and techniques.
• We consider the phased model to consist of the following phases:
Analysis phase.
Design phase.
Implementation phase.
Testing.
Maintenance.
• The basic phased model is presented in figure. This model is sometimes called a “waterfall chart”.
• Analysis phase of two phases: planning and requirements definitions.
• The project plan contains the life-cycle model to be used, the originated structure for the project, the preliminary cost and resource estimates, preliminary staffing requirements, tools and techniques to be used and standard practices to be followed.
• Preliminary estimates are prepared during the planning phase.
• Requirements definition is concerned with identifying the basic functions of the software component in a hardware/software/people system.
• In the phased model, software design follows analysis. Design is concerned with identifying software components (functions, data streams and the data stores),specifying relationship among components, specifying software structure, maintaining a record of design decisions and providing a blueprint for the implementation phase. Design consists of architectural .Design and detailed design.
Figure: The phased model of the software life cycle:
• Architectural design involves indentifying the software components, decoupling and decomposing them in to processing modules and conceptual data structures and specifying the interconnections among components.
• Detailed design is concerned with the details of “how to”: how to package the processing modules and how to implement the processing algorithms. Data structures and inter connections among modules and the data structure.
• Detailed design involves adaptation of existing code modification of standard algorithms invention of new algorithms, design of data representation and packaging of the software product.
• Errors discovered during the implementation phase may include errors in the data interfaces between routines. Logical errors in the algorithms errors in data structure layout and failure to account for various processing cases.
• One of the primaries to software development is to eliminate requirement and design errors from an evolving software product before implementations begins.
• System testing involves two kinds of activities: integration testing, acceptance testing.
• Developing a strategy for integrating the components of a software system into a functioning whole requires careful planning so that modules are available for integration when needed.
• Acceptance testing involves planning and execution of various types of tests in order to demonstrate that the implemented software system satisfies the requirements stated in the requirements document.
Milestones, documents and reviews:
• Another view of software cycle that emphasis the milestones, documents and reviews. Throughout product development.
• Establishing milestones review point’s standardized documents and management sign-offs can improve product visibility.
• The following discussion presents typical documents, project milestones, reviews and sign-offs used in the phased model of software development.
• Some of the terminology is adapted from the IEEE standard for software quality assuarances plans: however our categorization is not the same as that of the IEEE standard.
• A system definition and project plan are prepared, using the formats of tables.
• A preliminary version of the user’s Manuel is prepared. The preliminary user’s manual provides a vehicle of communication between customer and developer.
• A software requirement specification is prepared. The requirement specification clearly and precisely defines each essential requirement for the software product as well as the external interfaces to hardware, firmware, other software and people.
• A preliminary version of the software verification plan is prepared, the preliminary version states methods to be used and the results to be obtained.
• A software requirement review is held to ensure the adequecy of the system definition, the project plan, the software requirement specification the software verification plan, and the preliminary user’s manuel.
• The design team, which may or may not be the same as the analysis team creates the software design specification in two stages.
• A preliminary design review is held to evaluate the adequacy of the architectural design in satisfying the software product specification.
• Following completion of detailed design a critical design review is held.
• During the design phase, the software verification plan is expanded to include methods that will be used to verify that the design is complete and consistent.
• A software verification review is held to evaluate the adequacy and completeness of the verification plan and to review the preliminary acceptance test plan.
• During the implementation phase, source code is written, debugged and unit tested, observing standard, practicing in the following areas.
* logical structure – comments.
* coding style – debugging.
* Data layout – unit testing.
• During implementation, source-code reviews are held.
• During product evolution, Inspection and walkthroughs are conducted to verify the completeness, consistency and suitability of the work products.
• The user’s manual the install tier and training plan’s and the software maintenance plan are completed during the implementation phase.
• Prior to product delivery, a final acceptance review is performed.
• Finally a project legacy is written.
The cost model:
• Another view of the software life cycle can be obtained by considering the cost of performing. The various activities in a software project.
• The cost of conducting a software is the sum of the costs incurred in conducting each phase of the project.
• Modifications and corrections to the products of previous phases are necessary because the process of the current phase will expose inaccuracies, inconsistencies and incompleteness no those products and have because changes in customer requirements, schedules, priorities and budget will dictate modifications.
• The cost of producing the system definition and the project plan is the cost of performing the planning functions and preparing the documents.
• The cost of preparing the software requirements specification includes the cost of performing requirements definitions and preparing the specification document.
• Similarly, the cost of design the performing the design activities and performing the design specification and the test plan.
• The cost product implementation is the cost of implementing, documenting, debugging and unit testing the source code plus the cost of completing the user manual
• The cost of system testing includes the cost of planning and conducting the tests plus the cost of modifying and correcting the source code and the external documents during system testing.
System definition: project plan.
The prototype-life-cycle model:
• A prototype incorpates component of the actual product .typically a prototype exhibits limited functionally capabilities low reliability and /or inefficient performance.
• There are several reason for developing a prototype one important reason is to a prototype input data formats, messages, reports and interactive dialogues for the customers.
• The second reason for complementing a prototype is explore technical issues in the propose product.
• The phased model is applicable then it is possible to write a reasonably complete set of specification for a software product. At the binging of the life cycle. The nature and extend of prototyping to be performed on a particular software project is dependent on the nature of the product.
Successive version:
• Product, development by the method of successive version is an extension prototyping in which an initial product skeleton is refined into increasing level is of capability this approach each successive version of the product is a functioning system capable of performing useful work.
Design and implementation of Analysis and design followed by
Successive versions. Implementation of Successive versions.
• The above figure illustrates the analysis phase followed by Successive versions. the dashed line indicates that assessment of versions. It may dictate the need for further analysis before version I+1.
• In figure version 1 through N of the product are designed prior to any implementation activities. In this case the characteristics of each Successive design will have been planned during the analysis phase.
• Particular organizations and particular projects may adopt the structure of are particular model.
• There are possible life-cycle models we have discussed four:
* The phased model.
* The cost model.
* The prototype model.
* Successive version model.
• Adopting a product life-cycle model provides standardized terminology for the project and increases the visibility of the products.
Planning an organizational structure:
• The planning task identifies external customers and internal product needs, conducts feasibility studies and monitors progress from beginning to end of the product life cycle.
• The development task specifies designs, implements, debugs, tests and integrates the product. The services tasks provides automated tools and computer, resources for all other tasks
• The publications tasks develop user’s manuals, installation, instructions principles of operation and other supporting documents. The quality assurances tasks provide independent evaluation of source code publications prior to releasing them customers.
• The support tasks promote the product trains, users. installs the product and provides continuing liaison between users and other tasks. the maintenance task provides error correction and major enhancement throughout the productive life of the software product.
• The quality assurance test might provide configuration management .the maintenance. Task might provide user liaison and the support task might be handled by the marketing department.
Project structure:
Project format:
Use of a project format involves assembling a team of programmers who conduct a project From start to finish project team members do product definitions design the product, improvement it, test it. conduct project reviews and prepare the supporting documents.
Functional format:
• In the functional approach to organization, a different team of programmers each of. The project and the work products pass from team to team as they evolve.
• A typical variation on the functional format involves three teams an analysis team a design and implementation team.
• Team members are periodically rotated functions to provide career development and to relive the tedium of over specification.
Matrix format:
The matrix format is illustrated in figure:
• Each development project has a project manager concerned only with that project. The Project manager is organizationally a manager of the planning functions.
• Each functional group particular in each project .software development team members being organizationally to the development function.
Programming team structure:
• Every programming team must have an internal structure. The best team structure for any particular projects depends on the nature of the project and the product and on the characteristics of the individual team members.
• Basic team structure includes the democratic team in which all team members participate in all decisions.
• A large product may utilize several programming teams. In this case each team should have responsibility for a well defined functional unit communicates with other4 units through well-defined interfaces.
Democratic teams:
• The management structures and communication paths in an egoless team are illustrated.
• In an egoless team goals are set and a decision made by group consensus group leadership. Rotates from member to member based on the tasks to be performed and the differing ability of the team members.
• Work products 9requirements, design, source code, user’s manual etc) are discussed openly and are freely examined by all team members.
(a) Structure (b) communication path.
• Advantages of democratic team structure include the oppurinity for each team member to contribute to decisions the oppurinity for team members to learn from one another.
• Democratic team structures have the disadvantage of communication overhead required. To reach decisions. Less individual responsibility and authority can result in less initiative and fewer personnel drive from team members.
Chief programmer’s teams:
• Chief programmer’s teams are highly structured. The management structure and communication paths of chieftains illustrated. The Chief programmer’s designs the
Product implements critical parts of the product and makes all major technical decisions Work is allocated to programmers by the chief programmers. The Chief programmer’s is
Assisted by administrative program managers.
• Chief programmer’s teams have the advantage of centralized decisions making and reduced communication paths.
(a) Programmers. (b) Communication paths.
Hierarchical team structure:
• The hierarchical team structure occupies a middle portion between the extremes of democratic teams and Chief programmer’s teams.
• Hierarchical team structure limits the number of communication paths in a project while permitting effective communication among team members who need to communicate with one other if a hierarchical product is to have three major subsystems.
(a) Junior programmers. (b) Communication path.
• A major disadvantage of a hierarchical structure is that the most technically competent programmer’s tend to be promoted into management positions.
• Three basic programming team structures the democratic structure and the hierarchical structure Variations on these structures are possible.
MBO (management by objectives):
Management by objectives is a related technique that is increasing popular in
Software organization. Using mbo, employees set their own goals and objectives with the help Of supervision.
MBO can be applied at all levels of an organization and can include both products oriented objectives such as completion of design or testing.
• Product oriented objectives.
• Self improvement objectives.
Management by objectives can have 20 to 30 members to complete the work. It work will complete within 6 months or more.
Other planning activities:
• It includes planning and configuration management.
• Quality assurance functions verification and validation.
• Planning phase utilize development tools and techniques.
Four major planning activities:
• Planning for configuration management and quality assurance.
• Planning for independest verification and validation.
• Plan phase - some development tools and techniques.
• * Estimation of cost.
* Develop a schedule.
• Pre-liminary estimate.