software engineering -...
TRANSCRIPT
Literature
● Ian Sommerville, Software Engineering, 9th Edition, Addison-Weley
● J.G. Brookshear, Computer Science: An Overview, Chapter 7
Aims
● Understand what software engineering is and what are the attributes of a good software.
● Determine some of the difficulties associated with developing and maintaining large software projects.
● Identify the standard phases in a project.
● Examine common methods and tools associated with software engineering.
What is software?
● Software is not just the programs but also all associated documentation and configuration data that is needed to make these programs operate correctly.
● Fundamental types of software product:
1) Generic products: produced by a development organization and sold on the open market to a customer who is able to buy them. E.g., software for PCs such as databases, word processors, drawing packages and project management tools.
2) Customized products: systems which are commissioned by a particular customer. E.g.: air traffic control system, systems written to support a particular business, etc.
What is software engineering?
● Engineering discipline concerned with all aspects of software production from early stages of system specification to maintaining the system after it has gone into use.
● Not just concerned with the technical processes of software development but also with activities such as software project management and with the development of tools, methods and theories to support software production.
The software life cycle
● Once software is developed, it enters the cycle of being used and modified that continues for the rest of the software's life.
Some reasons why software development is so hard
● Lack of standards and reliable metrics:
– The software industry is only about 50 years old;
– We still have a long way to go before we have the body of experience behind us that the construction and manufacturing industries have.
– Lack of quantitative techniques, called metrics, for measuring the properties of software.
E.g., Mechanical engineers have tried and tested procedures and can measure the wear and tear of the components they work with; but no such luxury is afforded the software engineer.
● Difficult to understand:
– The modification phase requires that a person studies the underlying program and its documentation until the program, or at least the pertinent part of the program, is understood.
– Acquiring this understanding can be a difficult task.
– Software is often discarded under the pretense that it is easier to develop a new system from scratch than to modify the existing package successfully
Continued ...
● Lack of pre-build components:
– Some other industries use mostly prefabricated materials and parts that have been tried and tested on many other projects.
– The software industry on the other hand doesn’t have the range of pre-built components that other industries have.
– This leads us to our next point. ● Every line of code is a potential point of failure:
– Because all new projects are custom built it follows that every line of code is unproven and therefore should be tested. However, in the real world, this is totally impractical!
– Testing a single line of code is only part of the challenge. No line of code exists on its own.
– All of this testing comes at a cost. The question to be answered on every project is – how critical is this software and how much testing should we do to ensure the software is correct?
Continued...
● Lack of user input:
– Some reasons: ● The users are too busy and have “more important”
things to do.● Relations between the user community and the I.T.
team are poor.– Without the involvement and input of a user
representative the project is doomed to failure.● Users don't know what they want until they see it:
Computer-Aided Software Engineering (CASE)
● Covers a wide range of different types of programs that are used to support software process activities such as requirements analysis, system modeling, debugging and testing.
● Some of these tools are little more than the word processors, spreadsheet software, and email communication systems.
● Others are more sophisticated packages designed primarily for software engineering environment
Attributes of a good software
● Maintainability: software should be written in such a way that it may evolve to meet the changing needs of customers. This is a critical attribute because software change is an inevitable consequence of a changing business environment.
● Dependability: software dependability has a range of characteristics, including reliability, safety and security. 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 cycles. Efficiency therefore includes responsiveness, processing time, memory utilization, etc.
● Usability: software must be usable, without undue effort, by the type of user for whome it is designed. This means that it should have an appropriate user interface and adequate documentation.
Software process
● 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.
Software specification
● The process of understanding and defining what services are required from the system and identifying the constraints on the system's operation and development.
● Four main phases (not carried out in a strict sequence):
a)Feasibility study
b)Requirements elicitation and analysis
c) Requirement specification
d)Requirements validation
a)Feasibility study
● An estimate is made whether:
– the identified user needs may be satisfied using current software and hardware technologies;
– the proposed system will be cost-effective from a business point of view;
– it can be developed within existing budgetary constraints.
● The result should inform the decision of whether to go ahead with a more detailed analysis.
b)Requirements elicitation and analysis
● The process of deriving the system requirements through:
– observation of the existing systems;
– discussions with potential users;
– Task analysis....● May involve of one or more system models or prototypes
● Helps understand the system to be specified.
c)Requirement specification
● Translating the information gathered into a document that defines a set of requirements.
● Two types of requirements may be included:
– User requirements: abstract statements of the system requirements
– System requirements: more detailed description of the functionality to the provided.
d)Requirements validation
● Checks the requirements for realism, consistency and completeness.
● Errors in the requirements documents are are discovered and modified to correct these problems.
Software design and implementation
● The process of converting the system specification into an executable system. Design is about how to build a system.
● Software design
– Design a software structure that realizes the specification
– Can impact: performance, safety and security, maintainability
● Implementation
– Translate this structure into an executable program.● The activities of design and implementation are closely related
and may be inter-leaved.
Design activities
● Architectural design, where you identify the overall structure of the system, the principal components (sometimes called sub-systems or modules), their relationships and how they are distributed.
● Interface design, where you define the interfaces between system components.
● Component design, where you take each system component and design how it will operate.
● Database design, where you design the system data structures and how these are to be represented in a database.
Software validation
● Intended to show that a system conforms to its specification and meets the requirement of the system customer.
● Testing is being performed at each stage of the software process, from requirement definition to program development.
Testing stages
● Component testing
– Individual components are tested independently;
– Components may be functions or objects or coherent groupings of these entities.
● System testing
– Testing of the system as a whole. Finding errors that result from unanticipated interactions between components.
● Acceptance testing
– Testing with customer data to check that the system meets the customer's needs.
Alpha and beta testing
● Alpha testing:
– performed on customized software;
– continues until the system developer and the client agree that the delivered system is an acceptable implementation of the system requirements.
● Beta testing:
– applies in case of systems sold to the open market;
– exposes the product to real use and detects errors that may not have been anticipated by the system builders.
Software evolution
● Change is inevitable in all large software projects.
– Business changes lead to new and changed system requirements;
– New technologies open up new possibilities for improving implementations;
– Changing platforms require application changes.● Change leads to rework so the costs of ts change include
both rework (e.g., re-analysing requirements) as well as the costs of implementing new functionality.
Continued...
● Distinction between software development and maintenance is becoming increasingly irrelevant.
● Few software systems are now completely new systems, and it makes much more sense to see software development and maintenance as a continuum.
Summary so far
● Software engineering involves all aspects of developing software products.
● SE phases are: specification, design and implementation, testing and evolution.
● The ordering of SE phases may differ (as we’ll see in the next lecture).
● Software engineers use common methods and tools to help produce quality products.
SE approaches and process models
● We have looked at some fundamental activities that are common to all the software processes.
● Now: SE approaches and software process models for managing these.
● The choice of SE approach depends on the project size, the project type, the SE team, etc.
● Plan-driven and agile approaches (may be used in combination).
Plan-driven (heavyweight) approaches
● Support comprehensive planning, thorough documentation, and extensive design.
● Tries to plan out a large part of a project in great detail over a long span of time.
● Based on a sequential series of steps, such as requirements definition, solution build, testing.
● Good choice when you have multiple teams working at different locations and you need tighter control to formalize key parts of the project.
● E.g., Waterfall model and spiral model.
Waterfall model
● First published model (in 1970) of the software development process.
● The following phase should not start until the previous phase has finished.
● Based on the fact that iterations are costly and involve significant rework.
Waterfall model – pros and cons
● Advantages:
– Documentation is produced at each stage;
– Fits well with other engineering process models.
● Disadventages:– Commitments must be made at an early stage in the
process, which makes it difficult to respond to changing customer needs.
Spiral model
● This approach explicitly identifies and attempts to reduce risk.
● Each phase is represented as a loop in a spiral. E.g., the inner loop might be concerned with system feasibility, the next with requirements definitions, etc.
● Each loop in split into four sectors: (i) Objective setting, (ii) risk assessment, (iii) development and validation, (iv) planning.
When to use a heavyweight approach?
● Significant overhead in planning, designing and documenting a system is justified when:
– the work of multiple development teams has to be coordinated;
– the system is a critical system;
– many different people will be involved in maintaining the software over its lifetime.
● Not tailored to:
– Small or medium-sized systems
– rapid software development.
Agile (lightweight) approaches
● Businesses now operate in a global, rapidly changing environment.
● Software is part of all business operations so it is essential that new software is developed quickly to take advantage of new opportunities.
● Rapid development and delivery is now often the most critical requirement for software system.
● Dissatisfaction with heavyweight approaches led to new agile methods.
The principles underlying agile methods
1)Customer involvement: customers should be closely involved throughout the development process. Their role is to provide and prioritize new system requirements and to evaluate the iterations of the system.
2) Incremental delivery: the software is developed in increments with the customer specifying the requirements to be included in each increment.
3) People not process: the skills of the development team should be recognized and exploited. Team members should be left to develop their own ways of working without prescriptive processes.
4) Embrace changes: expect the system requirements to change, so design the system to accommodate these changes.
5) Maintain simplicity: focus on simplicity in both the software being developed and in the development process.
Issues behind agile methods
1) The customers are subject to other pressures and cannot take full part in the software development.
2) Individual team members may not have suitable personalities to interact well with other team members.
3) Prioritizing changes can be extremely difficult, especially in systems where there are many stakeholders.
4) Maintaining simplicity requires extra work. The team members may not have time to carry out desirable system simplifications.
When to use agile methods?
● Best suited to the development of small or medium-sized business systems and personal computer products.
● Not well suited to:
– large-scale systems development with the development teams in different places;
– complex interactions with other hardware and software systems;
– critical systems development where a detailed analysis of all of the system requirements in necessary to understand their safety and security implications.
Extreme programming (XP)
● Probably the best-know agile method;
● All requirements are expressed as scenarios (called user stories), which are implemented directly as a series of task.
● The customer is part of the development team and discusses scenarios with other team members.
● Programmers work in pairs and develop test for each task before writing the code.
Practices of XP
1) Incremental development is supported through small, frequent releases of the system.
2) Customer involvement is supported through the full-time engagement of the customer in the development team.
3) People, not process, are supported through pair programming, collective ownership of the system code, and a sustainable development process that does not involve excessively long working hours.
4) Change is supported through regular system releases, test-first development and continuous integration.
5) Maintaining simplicity is supported through constant refactoring to improve code quality and using simple designs that do not anticipate future changes to the system.
Pair programming - innovative practice of XP
● Programmers work in pairs to develop the software.
● Advantages:
– Supports the idea of common ownership and responsibility for the system.
– Each line of code is looked at by at least two people. Code inspections and reviews are very successful in discovering a high percentage of software errors.
– It helps support refactoring, which is the process of software improvement.
Prototyping
● Based on the idea of developing an initial implementation, exposing this to user comments and refining it through many versions until an adequate system has been developed.
● Specification, development and validation activities are interleaved rather than separate, with rapid feedback across activities.
● Two fundamental types of prototyping:
– Evolutionary prototyping: development begins with the parts that are well understood The system evolves by adding new features proposed by the customer.
– Throwaway prototyping: concentrates in experimenting with the customer requirements that are poorly understood.
Prototyping – pros and cons
● Advantages:
– Produces systems that meet the immediate customer needs.
– Appropriate for small and medium-sized systems.● Disadvantages:
– Customers may not understand the prototype limitation (why spend more time and money if they have a working version?)
– Systems are poorly structured
– Incorporating changes becomes difficult and costly.
– Not suitable for large, complex, long-life systems.
41
Incremental approach
● May be plan-driven or agile.
● Combines the advantages of waterfall model and prototyping.
● Customers identify in outline, the services to be provided by the system, and prioritize the services.
● Each increment provides a subset of the system functionalities.
● FINISISH THIS:::::::::::::::::::::::::::::::::::::::::::::::::
●
Incremental approach – pros and cons
● Advantages:
– Customers can use the system immediately.
– There is a lower risk of overall project failure. Although problems may be encountered in some increments, it is likely that some will be successfully delivered to the customer.
– As the highest priority services are delivered first, it is inevitable that the most important system services receive the most testing.
● Disadvantages:
– Difficult to map customer's requirement onto increments of the right size.
– It can be hard to identify common facilities that are needed by all increments.
Other approaches
● Plan-driven and agile approaches presume engineering within a business environment.
● Software systems can, however, be engineered using less controlled approaches.
● Examples:
– Cowboy Coding
– Free Software/Open Source
Cowboy coding
● The SE anti-pattern.
● Programmers have autonomy over the development process. This includes control of the project's schedule, languages, algorithms, tools, frameworks and coding style.
● Little participation by business users.
● A cowboy coder can be a lone developer or part of a group of developers working with minimal process or discipline.
● Can be useful for small projects and sometimes these pay off.
Some projects that started out Cowboy
● Abode Photoshop
● Apache HTTP Server
● Linux
● MySQL
● Most student projects
Free Software: Open Source Development
● Free as in freedom
– The software can be used, studied, modified and redistributed without restriction.
– the source code is openly shared so that people are encouraged to voluntarily improve the design of the software.
● The software evolves by the users, for the users.
● Examples:
– Linux
– Eclipse IDE
– Mozilla Firefox
Summary
● There are a number of approaches to SE including:
– Heavyweight (plan-driven)
– Lightweight (agile)
– Cowboy coding
– Open Source● They each have strengths and weaknesses
● Influencing factors include
– Size of project
– Knowledge of requirements
– Delivery environment
– Philosophy