Presentation is loading. Please wait.

Presentation is loading. Please wait.

S OFTWARE E NGINEERING C ONCEPT B y Rubel Biswas.

Similar presentations


Presentation on theme: "S OFTWARE E NGINEERING C ONCEPT B y Rubel Biswas."— Presentation transcript:

1 S OFTWARE E NGINEERING C ONCEPT B y Rubel Biswas

2 D EFERENCE COMPUTER SCIENCE A ND S OFTWARE ENGINEERING Computer science (CS) is the systematic study of algorithmic methods for representing and transforming information, including their theory, design, implementation, application, and efficiency. Computer engineering concentrates its effort on the ways in which computing ideas are mapped into working physical systems. Software engineering focuses on how to design and build software in teams

3 S OFTWARE P ROCESS A structured set of activities required to develop a software system Specification: what the system should do and its development constraints Design: production of the software system Validation: checking that the software is what the customer wants Evolution: changing the software in response to changing demands A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective.

4 S OFTWARE P ROCESS ( MORE ) Software Engineering processes are composed of many activities, notably the following: Requirements Analysis Extracting the requirements of a desired software product is the first task in creating it. While customers probably believe they know what the software is to do, it may require skill and experience in software engineering to recognize incomplete, ambiguous or contradictory requirements. Specification Specification is the task of precisely describing the software to be written, in a mathematically rigorous way. In practice, most successful specifications are written to understand and fine-tune applications that were already well- developed, although safety-critical software systems are often carefully specified prior to application development. Specifications are most important for external interfaces that must remain stable. Software architecture The architecture of a software system refers to an abstract representation of that system. Architecture is concerned with making sure the software system will meet the requirements of the product, as well as ensuring that future requirements can be addressed. Implementation Reducing a design to code may be the most obvious part of the software engineering job, but it is not necessarily the largest portion. Testing Testing of parts of software, especially where code by two different engineers must work together, falls to the software engineer. Documentation An important task is documenting the internal design of software for the purpose of future maintenance and enhancement. Training and Support A large percentage of software projects fail because the developers fail to realize that it doesn't matter how much time and planning a development team puts into creating software if nobody in an organization ends up using it. People are occasionally resistant to change and avoid venturing into an unfamiliar area, so as a part of the deployment phase, its very important to have training classes for the most enthusiastic software users (build excitement and confidence), shifting the training towards the neutral users intermixed with the avid supporters, and finally incorporate the rest of the organization into adopting the new software. Users will have lots of questions and software problems which leads to the next phase of software.

5 W HAT IS C OMPUTER -A IDED S OFTWARE E NGINEERING ?????? Computer-aided software engineering (CASE) is software to support software development and evolution processes. Upper-CASE – Tools to support the early process activities of requirements and design Lower-CASE – Tools to support later activities such as programming, debugging and testing

6 TOOL T YPE E XAMPLE C OMPUTER -A IDED S OFTWARE E NGINEERING

7 W HAT ARE THE ATTRIBUTES OF GOOD SOFTWARE ? The software should deliver the required functionality and performance to the user and should be maintainable, dependable and acceptable. Maintainability Software must evolve to meet changing needs (scalable); Dependability Software must be trustworthy (reliable, secured and safe); Efficiency Software should not make wasteful use of system resources; Acceptability Software must accepted by the users for which it was designed. This means it must be understandable, usable and compatible with other systems.

8 W HAT ARE THE KEY CHALLENGES FACING S OFTWARE E NGINEERING ?????? Heterogeneity Developing techniques for building software that can cope with heterogeneous platforms and execution environments; Delivery Developing techniques that lead to faster delivery of software; Trust Developing techniques that demonstrate that software can be trusted by its users. Reliable, Secured and Safe.

9 G ENERIC S OFTWARE P ROCESS M ODELS A simplified representation of a software process, presented from a specific perspective Examples of process perspectives: Workflow perspective represents inputs, outputs and dependencies Data-flow perspective represents data transformation activities Role/action perspective represents the roles/activities of the people involved in software process Generic process models Waterfall Evolutionary development Formal transformation Integration from reusable components

10 W ATERFALL M ODEL

11 W ATERFALL MODEL PROBLEMS !!!!!!!!!1 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.

12 E VOLUTIONARY DEVELOPMENT

13 Exploratory development Objective is to work with customers and to evolve a final system from an initial outline specification. Should start with well-understood requirements and add new features as proposed by the customer. Throw-away prototyping Objective is to understand the system requirements. Should start with poorly understood requirements to clarify what is really needed.

14 S PIRAL MODEL OF THE SOFTWARE PROCESS

15  Focuses attention on reuse options.  Focuses attention on early error elimination.  Puts quality objectives up front.  Integrates development and maintenance.  Provides a framework for hardware/software development.  Contractual development often specifies process model and deliverables in advance.  Requires risk assessment expertise.

16

17 S PIRAL MODEL SECTORS Objective setting Specific objectives for the phase are identified. Risk assessment and reduction Risks are assessed and activities put in place to reduce the key risks. Development and validation A development model for the system is chosen which can be any of the generic models. Planning The project is reviewed and the next phase of the spiral is planned.

18 S PIRAL MODEL C ONT... The spiral model is similar to the incremental model, with more emphasis placed on risk analysis. The spiral model has four phases: Planning, Risk Analysis, Engineering and Evaluation. A software project repeatedly passes through these phases in iterations (called Spirals in this model). The baseline spiral, starting in the planning phase, requirements are gathered and risk is assessed. Each subsequent spirals builds on the baseline spiral. Requirements are gathered during the planning phase. In the risk analysis phase, a process is undertaken to identify risk and alternate solutions. A prototype is produced at the end of the risk analysis phase.incremental model

19 S PIRAL MODEL C ONT... Software is produced in the engineering phase, along with testing at the end of the phase. The evaluation phase allows the customer to evaluate the output of the project to date before the project continues to the next spiral.testing

20 A DVANTAGES OF S PIRAL MODEL High amount of risk analysis hence, avoidance of Risk is enhanced. Good for large and mission-critical projects. Strong approval and documentation control. Additional Functionality can be added at a later date. Software is produced early in the software life cycle.software life cycle

21 D ISADVANTAGES OF S PIRAL MODEL Can be a costly model to use. Risk analysis requires highly specific expertise. Project’s success is highly dependent on the risk analysis phase. Doesn’t work well for smaller projects.

22 Thanks


Download ppt "S OFTWARE E NGINEERING C ONCEPT B y Rubel Biswas."

Similar presentations


Ads by Google