Software Engineering by uu3u1KY

VIEWS: 4 PAGES: 47

									            Software Engineering

                   CIS 375
                Bruce R. Maxim
                 UM-Dearborn

12/8/2011                          1
            What is CIS 375 about?
• Project Management
• Structured Methodology
• Object Oriented Analysis / Object
  Oriented Design
• User Interface Design
• Testing and Validation

12/8/2011                             2
       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)

12/8/2011                                        3
 Historical Project Cost Allocation




12/8/2011                             4
            Early Error Detection
               Saves Money




12/8/2011                           5
            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


12/8/2011                              6
            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.



12/8/2011                                        7
            Failures Over Time




            Hardware    Software



12/8/2011                          8
             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.


12/8/2011                                                9
            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.

12/8/2011                                      10
            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.

12/8/2011                                       11
            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.

12/8/2011                                         12
    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

12/8/2011                                                 13
    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

12/8/2011                                               14
    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
12/8/2011                                                  15
            Software Engineering
1. A strategy for producing high quality
   software.
2. Software engineering encompasses a
   process, management techniques, technical
   methods, and the use of tools.




12/8/2011                                  16
     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).


12/8/2011                                         17
     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).


12/8/2011                                         18
     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).

12/8/2011                                               19
            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.
12/8/2011                                      20
Components and Subsystems




12/8/2011               21
            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.


12/8/2011                                22
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



12/8/2011                              23
     Software Life Cycle Phases
1.    Requirements, analysis, and design phase.
2.    System design phase.
3.    Program design phase.
4.    Program implementation phase.
5.    Unit testing phase.
6.    Integration testing phase.
7.    System testing phase.
8.    System delivery.
9.    Maintenance.

12/8/2011                                         24
            Umbrella Activities
                 Part 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)

12/8/2011                                             25
            Umbrella Activities
                 Part 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.)

12/8/2011                                             26
        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
12/8/2011                                               27
     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


12/8/2011                                         28
            Linear Sequential Model
               or Waterfall Model




12/8/2011                             29
            Prototyping Model




12/8/2011                       30
            Spiral Model




12/8/2011                  31
      Fourth Generation Language
              Techniques




12/8/2011                          32
   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

12/8/2011                                                              33
            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

12/8/2011                               34
            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

12/8/2011                                     35
    Unified Process Work Products
            Inception Phase
•   Vision document
•   Initial use-case model
•   Initial project glossary
•   Initial business case
•   Initial risk assessment
•   Project plan (phases and iterations)
•   Business model
•   Prototypes


12/8/2011                                  36
    Unified Process Work Products
           Elaboration 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

12/8/2011                                                 37
    Unified Process Work Products
          Construction Phase
•   Design model
•   Software components
•   Integrated software increment
•   Test plan
•   Test cases
•   Support documentation (user, installation, increment)




12/8/2011                                               38
   Unified Process Work Products
          Transition Phase

• Delivered software increment
• Beta test reports
• User feedback




12/8/2011                          39
       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).



12/8/2011                                 40
         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.

12/8/2011                                      41
         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.
12/8/2011                                              42
         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.
12/8/2011                                             43
       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


12/8/2011                                        44
               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.
12/8/2011                                       45
        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.
12/8/2011                                   46
              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)



12/8/2011                                                           47

								
To top