Software engineering
1 / 47

Software Engineering - PowerPoint PPT Presentation

  • Updated On :

Software Engineering. CIS 375 Bruce R. Maxim UM-Dearborn. What is CIS 375 about? . Project Management Structured Methodology Object Oriented Analysis / Object Oriented Design User Interface Design Testing and Validation. Why is software engineering important?.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Software Engineering' - kira

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Software engineering

Software Engineering

CIS 375

Bruce R. Maxim


What is cis 375 about
What is CIS 375 about?

  • Project Management

  • Structured Methodology

  • Object Oriented Analysis / Object Oriented Design

  • User Interface Design

  • Testing and Validation

Why is software engineering important
Why is software engineering important?

To avoid costly errors caused by software:

  • Lost Voyager Spacecraft (one bad line of code caused failure)

  • 3 Mile Island (poor user interface design)

  • Several people killed by a radiation machine (no means of catching operator errors)

  • Commercial aircraft accidentally shot down during Gulf War (poor user interface)

Software designer characteristics
Software Designer Characteristics

  • Studies have found that many designers tend to suffer from the “not invented here” syndrome

  • 80% of most software errors can be discovered by peer review (proof reading) the code or document

Software characteristics
Software Characteristics

  • Software is both a product and a vehicle for developing a product.

  • Software is engineered not manufactured.

  • Software does not wear out, but it does deteriorate.

  • Most software is still custom-built.

Failures over time
Failures Over Time



Software crisis
Software Crisis

  • Software failures receive a lot more publicity than software engineering success stories.

  • The software crisis predicted thirty years ago has never materialized and software engineering successes now outnumber the failures.

  • The problems that afflict software development are more likely to be associated with how to develop and support software properly, than with simply building software that functions correctly.

Software myths part 1
Software Myths – Part 1

  • Software standards provide software engineers with all the guidance they need.

  • People with modern computers have all the software development tools they need

  • Adding people is a good way to catch up when a project is behind schedule.

  • Giving software projects to outside parties to develop solves software project management problems.

Software myths part 2
Software Myths – Part 2

  • A general statement of objectives from the customer is all that is needed to begin a software project.

  • Project requirements change continually and change is easy to accommodate in the software design.

  • Once a program is written, the software engineer's work is finished.

Software myths part 3
Software Myths – Part 3

  • There is no way to assess the quality of a piece of software until it is actually running on some machine. The only deliverable from a successful software project is the working program.

  • Software engineering is all about the creation of large and unnecessary documentation not shorter development times or reduced costs.

Software evolution part 1
Software Evolution – Part 1

  • Law of continuing change

    • Systems must be continually adapted or they become progressively unsatisfactory

  • Law of increasing complexity

    • As system evolves its complexity increases unless work is done to reduce the complexity

  • Law of self-regulation

    • System evolution is self-regulating with its process and product measures following near normal distributions

Software evolution part 2
Software Evolution – Part 2

  • Law of conservation of Organizational Stability

    • Average effective global activity rate for an evolving systems is invariant over the product lifetime

  • Law of conservation of familiarity

    • As system evolves all stakeholders must maintain their mastery of its content and behavior to achieve satisfactory evolution

Software evolution part 3
Software Evolution – Part 3

  • Law of continuing growth

    • Functional content of system must be continually increased to maintain user satisfaction over its lifetime

  • Law of declining quality

    • System quality will appear to decline unless the system is rigorously maintained and adapted to environment changes

  • Feedback system law

    • System evolution processes must be treated as multi-level, multi-loop, multi-agent feedback systems to achieve significant improvement

Software engineering1
Software Engineering

  • A strategy for producing high quality software.

  • Software engineering encompasses a process, management techniques, technical methods, and the use of tools.

What is high quality software
What is high quality software?

  • It must be useful (to the original customer).

  • It must be portable (work at all of the customer’s sites).

  • It must be maintainable.

  • It must be reliable.

  • It must have integrity (produces correct results, with a high degree of accuracy).

What is high quality software1
What is high quality software?

  • It must be efficient.

  • It must have consistency of function (it does what the user would, reasonably expect it to do).

  • It must be accessible (to the user).

  • It must have good human engineering (easy to learn and easy to use).

Software engineering phases
Software Engineering Phases

  • Definition phase

    • focuses on what (information engineering, software project planning, requirements analysis).

  • Development phase

    • focuses on how (software design, code generation, software testing).

  • Support phase

    • focuses on change (corrective maintenance, adaptive maintenance, perfective maintenance, preventative maintenance).

Systems approach
Systems Approach

  • A set of entities.

  • A set of activities.

  • Descriptions of entity relationships.

  • System boundaries.

  • Distinguish between activities (processes, methods) and objects (data).

  • Determine the relationships between the objects.

Engineering approach
Engineering Approach

  • The art of producing a system involves the craft of software production

  • Engineers think that computer scientists should be able to fabricate software systems out of off the shelf components like hardware designers do.

Why doesn t this approach work
Why doesn’t this approach work?

  • Customers are not capable of describing their needs completely or precisely.

  • Customers or programmers change the specifications as development proceeds

Software life cycle phases
Software Life Cycle Phases

  • Requirements, analysis, and design phase.

  • System design phase.

  • Program design phase.

  • Program implementation phase.

  • Unit testing phase.

  • Integration testing phase.

  • System testing phase.

  • System delivery.

  • Maintenance.

Umbrella activities part 1
Umbrella ActivitiesPart 1

  • Software project tracking and control (allows team to assess progress and take corrective action to maintain schedule)

  • Risk management (assess risks that may affect project outcomes or quality)

  • Software quality assurance (activities required to maintain software quality)

  • Formal technical reviews (assess engineering work products to uncover and remove errors before they propagate to next activity)

Umbrella activities part 2
Umbrella ActivitiesPart 2

  • Measurement (define and collect process, project, and product measures to assist team in delivering software meeting customer needs)

  • Software configuration management (manage effects of change)

  • Reusability management (defines criteria for work product reuse and establish mechanisms to achieve component reuse)

  • Work product preparation and production (activities to create models, documents, logs, forms, lists, etc.)

Comparing process models part 1
Comparing Process Models Part 1

  • Overall flow and level of interdependencies among tasks

  • Degree to which work tasks are defined within each framework activity

  • Degree to which work products are identified and required

  • Manner in which quality assurance activities are applied

  • Manner in which project tracking and control activities are applied

Comparing process models part 2
Comparing Process Models – Part 2

  • Overall degree of detail and rigor of process description

  • Degree to which stakeholders are involved in the project

  • Level of autonomy given to project team

  • Degree to which team organization and roles are prescribed

Linear sequential model or waterfall model
Linear Sequential Model or Waterfall Model

Specialized process models
Specialized Process Models

  • Component-Based Development

    • spiral model variation in which applications are built from prepackaged software components called classes

  • Formal Methods Model

    • rigorous mathematical notation used to specify, design, and verify computer-based systems

  • Aspect-Oriented Programming

    • provides a process for defining, specifying, designing, and constructing software aspects like user interfaces, security, and memory management that impact many parts of the system being developed

Unified process
Unified Process

  • Use-case driven, architecture centric, iterative, and incremental software process

  • Attempts to draw on best features of traditional software process models and implements many features of agile software development

Unified process phases
Unified Process Phases

  • Inception phase

    • customer communication and planning

  • Elaboration phase

    • communication and modeling

  • Construction phase

  • Transition phase

    • customer delivery and feedback

  • Production phase

    • software monitoring and support

Unified process work products inception phase
Unified Process Work ProductsInception Phase

  • Vision document

  • Initial use-case model

  • Initial project glossary

  • Initial business case

  • Initial risk assessment

  • Project plan (phases and iterations)

  • Business model

  • Prototypes

Unified process work products elaboration phase
Unified Process Work ProductsElaboration Phase

  • Use-case model

  • Functional and non-functional requirements

  • Analysis model

  • Software architecture description

  • Executable architectural prototype

  • Preliminary design model

  • Revise risk list

  • Project plan (iteration plan, workflow, milestones)

  • Preliminary user manual

Unified process work products construction phase
Unified Process Work ProductsConstruction Phase

  • Design model

  • Software components

  • Integrated software increment

  • Test plan

  • Test cases

  • Support documentation (user, installation, increment)

Unified process work products transition phase
Unified Process Work ProductsTransition Phase

  • Delivered software increment

  • Beta test reports

  • User feedback

Capability maturity model
Capability Maturity Model

Level 1: Initial Process

  • Ad-hoc approach to software design.

  • Inputs are ill defined.

  • Outputs are expected (transitions not defined or controllable).

Capability maturity model1
Capability Maturity Model

Level 2: Repeatable Process

  • Requirements are input.

  • Code is output.

  • Constraints are things like budget & time.

  • Metrics - project related:

    • Software size.

    • Personnel effort.

    • Requirement validity.

    • Employee turnover.

Capability maturity model2
Capability Maturity Model

Level 3: Defined Process

  • The activities of the process have clearly defined entry & exit conditions.

  • Intermediate products - well defined and easily visible.

  • Metrics:

    • Requirements complexity.

    • Code complexity.

    • Failures discovered.

    • Code defects discovered.

    • Product defect density.

    • Pages of documentation.

Capability maturity model3
Capability Maturity Model

Level 4: Managed Process

  • Information from early process activities can be used to schedule later process activities.

  • Metrics are defined and analyzed to suit the development organization:

    • Process type.

    • Producer reuse.

    • Consumer reuse.

    • Defect identification mechanism.

    • Defect density - model for testing.

    • Configuration management scheme.

    • Module completion rate over time.

Capability maturity model4
Capability Maturity Model

Level 5: Optimizing Process

  • Measures from activities are used to improve processes

  • Continuous process improvement is enabled by quantitative feedback from the process and testing innovative ideas

  • Metrics are selected to enhance feedback into evaluation mechanism

Using metrics
Using Metrics

  • Assess the process level.

  • Determine metrics to use.

  • Recommend metrics, tools, techniques.

  • Estimate project costs and schedule.

  • Collect metrics at the appropriate level.

  • Construct a project database.

  • Evaluate cost and schedule.

  • Evaluate productivity and quality.

  • Form a basis for future estimates.

Benefits of using metrics
Benefits of Using Metrics

  • Enhanced understanding of the process.

  • Increased control over the process.

  • Clear migration path to a more mature process.

  • More accurate estimates of cost and scheduling of staff.

  • More objective evaluation of changes needed (techniques, tools, methods, ect.).

  • More accurate estimation of changes on project cost and schedule.

Software patterns
Software Patterns

  • Templates or methods for describing important characteristics of software processes

  • Software teams can combine software patterns to construct processes that best meet the needs of specific projects

    • Task pattern (defines engineering action or work task)

    • Stage pattern (defines framework activity for the process)

    • Phase pattern (defines sequence or flow of framework activities that occur within process)