Kelis king - introduction to s.e.
- 1. Kelis King Introduction to S.E.
- 2. Software Crisis It was in late 1960’s •Many software projects failed. • Many software projects late, over budget, providing unreliable software that is expensive to maintain. • Many software projects produced software which did not satisfy the requirements of the customer. •Complexities of software projects increased as hardware capability increased. •Larger software system is more difficult and expensive to maintain. •Demand of new software increased faster than ability to generate new software. All the above attributes of what was called a ‘Software Crisis’. So the term ‘Software Engineering’ first introduced at a conference in late 1960’s to discuss the software crisis.
- 3. Why software engineering? Once the need for software engineering was identified and software engineering recognized as a discipline-- • The late 1970’s saw the widespread evolution of software engineering principles. • The 1980’s saw the automation of software engineering and growth of CASE (Computer Aided Software Engineering). • The 1990’s have seen increased emphasis on the ‘management’ aspects of projects and the use of standard quality and ‘process’ models like ISO 9001 and the Software Engineering Institute’s Software Capability Maturity Model (CMM). These models help organizations put their software development and management processes in place
- 4. What is software Engineering? • In1969 Fritz Bauer defined software eng. as, ‘the establishment and use of sound engineering principles in order to obtain, economically, software that is reliable and works efficiently on real machines’. • According to Boehm, software engineering involves, ‘the practical application of scientific knowledge to the design and construction of computer programs and the associated documentation required developing, operating and maintaining them’ • IEEE, in its standard 610.12-1990, defines software engineering as: (i) The application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software; that is, the application of engineering to software. (ii) The study of approaches as in (i). • By combining all the above definition we can define software engineering as, ‘Software engineering is the technological and managerial discipline concerned with systematic production and maintenance of software products that are developed and modified on time and within cost estimates.’
- 5. Goal of software engineering The primary goals of software engineering are: • To improve the quality of the software products. • To increase the productivity & • To give job satisfaction to the software engineers.
- 6. Foundation of Software engineering Software engineering is a technological discipline distinct from, but based on the foundation of the following disciplines: • Computer Science • Management Science • Economics • System Engineering & • Communication Skills
- 7. The relationship of software engineering with other disciplines • Computer Science gives the scientific foundation to the software as electrical engineering relies on physics. • Management Science provides the foundation for software project management. Since software engineering is labor intensive activity, it requires both technical and managerial control. • Economics provides the foundation for resource estimation and cost control. Since, computing system must be developed and maintained on time and within cost estimates; thus economics plays an important role. • System Engineering is the field concerned with studying complex systems. Software is often a component of a much larger system. For example, the software in a factory monitoring system or the flight software on an airplane; is just the component of more complex system. System engineering techniques can be applied to study of such systems • Good oral, written and interpersonal communication skills are crucial for the software engineers, because software engineering activities occur within an organizational context, and a high degree of communication is required among customers, managers, software engineers, hardware engineers and other technical workers.
- 8. Difference of s/w eng. with traditional engineering • Software is intangible. It has no mass, no volume, no color, no odor--- no physical properties. Source code is merely a static image of computer program, and while the effects produced by a program are often observable, the program itself not. • Software doesn’t degrade with time as hardware does. Software failures are caused by design and implementation error, not by degradation over time • There is always an obscurity in the interface between software modules. It is difficult to design a software system so that all the control and interfaces among modules are explicit, and so that the modules do not interact to produce unexpected side effects when they invoked one another.
- 9. …. difference • In classical engineering disciplines, the engineer is equipped with tools and the mathematical maturity to specify the properties of the product separately from those of design. • The typical software engineering relies much more on experience and judgment rather than mathematical formula. While experience and judgment are necessary, formal analysis are also essential in the practice of engineering.
- 10. The role of software engineer The evolution of software engineering field has defined the role of the software engineer. A software engineer should have the following qualities: • Should be a good programmer, be well-versed in data structures and algorithms, and be fluent in one or more programming languages. Should be familiar with several design approaches, be able to translate vague requirements and desires into precise specifications and be able to converse with the use of a system in terms of applications. Needs the ability to move among several levels of abstraction at different stages of the project, from specific application procedures and requirements, to abstraction for software systems, to a specific design for system and finally to the detailed coding level.
- 11. The characteristics of software engineer Should be able to build and use a model of the application to guide choices of the many trade- offs that he or she will face. The model is used to answer questions about both the behavior of the system and its performance. Needs communication skills and interpersonal skills. He also needs the ability to schedule work both of his own and that of others.
- 12. What is well engineered software? If the software system does what the user wants, and can be made to continue to do what the user wants, it is well engineered. • Any well engineered software system should have the following attributes: • Be easy to maintain • Be reliable • Be efficient • Provides an appropriate user interface The development of software must make trade-offs between these attributes.
- 13. Distribution of software effort The typical life-span for a typical software product is 1 to 3 years in development and 5 to 15 years in use. The distribution of effort between development and maintenance has been variously reported depending on the type of software as 40/60, 30/70 and 10/90. Maintenance: • Corrective: Even with the best quality of software, it is likely that customer will uncover defect in software. Corrective maintenance changes the software to correct the defects. • Adaptive: Over time, the original environment (CPU, OS, business rules, external product character etc.) for which the software was developed may change. Adaptive maintenance results in modification to the software to accommodate the change to its environment. • Perfective: As the software is used, the customer / user will recognize additional function that will provide benefit. Perfective maintenance extends the software beyond its original functional requirements.
- 14. The software product The objective of software engineering is to produce software products. Computer software is the product that software engineers design and built. Software products are software systems delivered to a customer with the documentation which describes how to install and use the system. • Software products fall into two broad classes: • Generic products: These are stand alone systems which are produced by a software development organizations/firms and sold on the open market to any customer who is able to buy them. • Customized products: These are systems which are commissioned by a particular customer. The software is developed specially for that customer by some developer.
- 15. …. Software products • Until the 1980’s, the vast majority of software systems which were sold that were customized and specially designed systems which run on large computers. They are expensive because all the development cost had to be met by a single client. • After the development of PCs, this situation has completely changed. The PC market is totally dominated by software products produces by companies such as Microsoft. These account for the vast majority of software sales. These are usually relatively cheap because their development cost is spread across hundred or thousands of different customers.
- 16. Difference between generic and customized software • The generic software product specifications are produced internally by the marketing department of the product company. They reflect what they think will sell. They are usually flexible and non- prescriptive. • For customized systems are often the basis for the contract between customer and developer. They are usually defined in detail and changes have to be negotiated and carefully costed.
- 17. Software product attributes The attributes of a software product are the characteristics displayed by the product, once it is installed and put in use. They are not the services provided by the product. Rather, they are concerned with the products dynamic behavior and the use made of the product. Examples of these attributes are therefore, efficiency, reliability, maintainability, robustness, portability and so on. The relative importance of these characteristics obviously varies from system to system.
- 18. … product attributes Product characteristics Description Maintainability It should be possible to evolve software to meet the changing needs of the customer. Dependability Software dependability includes a range of characteristics including reliability, security and safety. Dependable software should not cause physical or economic damage in the event of system failure. Efficiency Software should not make wasteful use of system resources such as memory and processor cycle Usability Software should have an appropriate user interface and documentation
- 19. ..product attributes Optimizing the above attribute is difficult as some are exclusive. For example, providing a better user interface may reduce system efficiency. The relationship between cost and improvement in each of the attribute is not linear one. Small improvement in any of these attributes may be devoted to optimizing particular attribute.
- 21. The software process • A structured set of activities required to develop a software system. • Many different software processes but all involve: – Specification – defining what the system should do; – Design and implementation – defining the organization of the system and implementing the system; – Validation – checking that it does what the customer wants; – Evolution – changing the system in response to changing customer needs. • A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective.
- 22. Software process descriptions • When we describe and discuss processes, we usually talk about the activities in these processes such as specifying a data model, designing a user interface, etc. and the ordering of these activities. • Process descriptions may also include: – Products, which are the outcomes of a process activity; – Roles, which reflect the responsibilities of the people involved in the process; – Pre- and post-conditions, which are statements that are true before and after a process activity has been enacted or a product produced.
- 23. Plan-driven and agile processes • Plan-driven processes are processes where all of the process activities are planned in advance and progress is measured against this plan. • In agile processes, planning is incremental and it is easier to change the process to reflect changing customer requirements. • In practice, most practical processes include elements of both plan-driven and agile approaches.
- 24. Software Development Life cycle (SDLC) • A life cycle model prescribes the different activities that need to be carried out to develop a software product and sequencing of these activities. • Also referred to as Systems Development Life cycle. • Every software product starts with a request for the product by the customer.- Production conception. • The software life cycle can be considered as the business process for software development and therefore is often referred to as a Software process. (SLCM). • Process models – More detailed and precise life cycle activities.
- 25. • Different stages in a life cycle model: After Product conception. The stages are: (Life cycle phase) Feasibility study stage Requirements analysis and specification. Design Coding Testing and Maintenance. • A SDLC is a series of identifiable stages that a software product undergoes during its lifetime. • A SDLC is a descriptive and diagrammatic representation of the software life cycle. • A life cycle model maps the different activities performed on a software product from its beginning to retirement into a set of life cycle phases.
- 26. • Why use a life cycle model? • Encourages development of software in a systematic and disciplined manner • S.D organisations have realized that adherence to a suitable well-defined life cycle model helps to produce good quality products and that too without time and cost overruns. • Why document a life cycle model? • A documented life cycle model, besides preventing misinterpretations that occur when the life cycle model is no adequately documented, also helps to identify inconsistencies, redundancies, and omissions in the development process
- 27. 1. The classical waterfall model Basic life cycle model- Theoretical way of developing software.
- 28. Classical Waterfall model phases • There are separate identified phases in the waterfall model: – Requirements analysis and definition – System and software design – Implementation and unit testing – Integration and system testing – Operation and maintenance • The main drawback of the waterfall model is the difficulty of accommodating change after the process is underway. In principle, a phase has to be complete before moving onto the next phase.
- 29. Classical Waterfall model problems • Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements. – Therefore, this model is only appropriate when the requirements are well-understood and changes will be fairly limited during the design process. – Few business systems have stable requirements. • The waterfall model is mostly used for large systems engineering projects where a system is developed at several sites. – In those circumstances, the plan-driven nature of the waterfall model helps coordinate the work.
- 30. 2. Structured Evolutionary Prototyping Model • Developers build a prototype during the requirements phase. • Prototype is evaluated by end users. • Users give corrective feedback. • Developers further refine the prototype. • When the user is satisfied, the prototype code is brought up to the standards needed for a final product.
- 31. Structured Evolutionary Prototyping Steps • A preliminary project plan is developed. • An partial high-level paper model is created. • The model is source for a partial requirements specification. • A prototype is built with basic and critical attributes • The designer builds – the database – user interface – algorithmic functions • The designer demonstrates the prototype, the user evaluates for problems and suggests improvements. • This loop continues until the user is satisfied.
- 32. Structured Evolutionary Prototyping Strengths • Customers can “see” the system requirements as they are being gathered. • Developers learn from customers. • A more accurate end product. • Unexpected requirements accommodated. • Allows for flexible design and development. • Steady, visible signs of progress produced. • Interaction with the prototype stimulates awareness of additional needed functionality.
- 33. Structured Evolutionary Prototyping Weaknesses • Tendency to abandon structured program development for “code-and-fix” development. • Bad reputation for “quick-and-dirty” methods • Overall maintainability may be overlooked. • The customer may want the prototype delivered. • Process may continue forever (scope creep).
- 34. When to use Structured Evolutionary Prototyping • Requirements are unstable or have to be clarified. • As the requirements clarification stage of a waterfall model. • Develop user interfaces. • Short-lived demonstrations. • New, original development. • With the analysis and design portions of object- oriented development.
- 35. Code-and-Fix Life-Cycle Model • No design • No specifications The easiest way to develop software The most expensive way for maintenance (i.e., maintenance nightmare) 35
- 36. Code-and-Fix Life-Cycle Model (Cont.) • The product is implemented without requirements or specifications, or any attempt at design. • The developers simply throw code together and rework it as many times as necessary to satisfy the client. • It is used in small project and is totally unsatisfactory for products of any reasonable size. 36
- 37. 3. Spiral Model Since end-user requirements are hard to obtain/define, it is natural to develop software in an experimental way: e.g. 1. Build some software 2. See if it meets customer requirements 3. If no go to 1 else stop.
- 38. This loop approach gives rise to structured iterative lifecycle models. In 1988 Boehm developed the spiral model as an iterative model which includes risk analysis and risk management. Key idea: on each iteration identify and solve the sub-problems with the highest risk.
- 39. Spiral model • Spiral with many loops. • Each loop of the spiral is called the phase of a software process. • Over each loop, one or more features of the product are elaborated and analysed and risks at that point of time are identified and resolved through prototyping. Based on this, the identified features are implemented.
- 40. 4 Quadrants of spiral model • 1st Quadrant: – The objectives are investigated, elaborated and analysed. – Risks are also identified. – Alternative Solutions are proposed • 2nd Quadrant: • Alternative solutions are evaluated to select best. • 3rd Quadrant: • Developing and verifying the next level of the product • 4th Quadrant: • Reviewing the results of the stages traversed so far with the customer. • Planning the next iteration around the spiral. :
- 41. Determine objectiv es, alternatives, & constr aints Spiral Model Evaluate alter nativ es, identify& resolv e r isks Risk analysis Risk analysis P1 Risk analysis Project P1 Prototype3 Prototype2 Prototype1 Requirements plan Concept of operation Software System Development plan Requirements validation Requirements Product Design Detailed Design Plan next phase Integration plan Design validation P2 Unit Test Code Develop & ver ify next level product Acceptance Test Integration &Test Project P2
- 42. Cycle 1, Quadrant IV: Determine Objectives, Alternatives and Constraints Project Start
- 43. Cycle 1, Quadrant I: Evaluate Alternatives, Identify, resolve risks Build Prototype
- 44. Cycle 1, Quadrant II: Develop & Verify Product Concept of Operation Activity
- 45. Cycle 1, Quadrant III: Prepare for Next Activity Requirements and Life cycle Planning
- 46. Cycle 2, Quadrant IV: Software Requirements Activity Start of Round 2
- 47. Spiral Model Strengths • Provides early indication of insurmountable risks, without much cost. • Users see the system early because of rapid prototyping tools. • Critical high-risk functions are developed first. • The design does not have to be perfect. • Users can be closely tied to all lifecycle steps. • Early and frequent feedback from users. • Cumulative costs assessed frequently.
- 48. Spiral Model Weaknesses • Time spent for evaluating risks too large for small or low- risk projects. • Time spent planning, resetting objectives, doing risk analysis and prototyping may be excessive. • The model is complex. • Risk assessment expertise is required. • Spiral may continue indefinitely. • Developers must be reassigned during non-development phase activities. • May be hard to define objective, verifiable milestones that indicate readiness to proceed through the next iteration.
- 49. 4. Evolutionary Model • Successive versions model. • Incremental model. • A simple working system is built, which subsequently undergoes many functionality improvements and additions until the desired system is realized . • Also sometimes referred to as design a little, build a little, test a little, deploy a little model. • That is once the requirements have been specified, the design, build, test and deployment activities are interleaved.
- 50. • The software requirements is first broken down into several modules(functional units) that can be incrementally constructed and delivered. • The development team first develop the core modules of the system. • The Core modules are those that don’t need services from the other modules. • The initial product Skelton is refined into increasing levels of capability by adding new functionalities in the successive versions.
- 53. Iterative Model • An iterative lifecycle model does not attempt to start with a full specification of requirements. • Instead, development begins by specifying and implementing just part of the software, which can then be reviewed in order to identify further requirements. • This process is then repeated, producing a new version of the software for each cycle of the model. • Consider an iterative lifecycle model which consists of repeating the following four phases in sequence:
- 54. Iterative Model
- 55. • A Requirements phase, in which the requirements for the software are gathered and analysed. Iteration should eventually result in a requirements phase that produces a complete and final specification of requirements. • A Design phase, in which a software solution to meet the requirements is designed. This may be a new design, or an extension of an earlier design. • An Implementation and Test phase, when the software is coded, integrated and tested. • A Review phase, in which the software is evaluated, the current requirements are reviewed, and changes and additions to requirements proposed.
- 56. Iterative Waterfall model • The iterative waterfall model is classical waterfall model with necessary changes so that it becomes applicable to practical software development projects. • The main change to the classical waterfall model is in the form of providing feedback paths from every phase to its preceding phase. • The feedback paths allows for correction of errors committed during a phase, as and when these are detected in a later phase. • The principle of detecting errors as close to their points of introduction as possible is known as phase containment of errors.
- 58. Comparison of Life-Cycle Models • Different life-cycle models have been presented – Each with its own strengths and weaknesses • Criteria for deciding on a model include: – The organization – Its management – The skills of the employees – The nature of the product • Best suggestion – “Mix-and-match” life-cycle model