1 software engineering. chapter-1 introduction to software engineering what is software ? computer...
TRANSCRIPT
1
SOFTWARE ENGINEERING
CHAPTER-1 INTRODUCTION TO SOFTWARE ENGINEERING
WHAT IS SOFTWARE ?
Computer programs and associated documentation
3
Software products may be developed for a particular customer or may be developed for a general market
Software products may beGeneric - developed to be sold to a range of
different customersBespoke (custom) - developed for a single
customer according to their specification
4
What is software engineering?
Software engineering is an engineering discipline which is concerned with all aspects of software production.
Software engineers should adopt a systematic and organised approach to their
work use appropriate tools and techniques depending on
the problem to be solved, the development constraints and the resources available
5
What is the difference between software engineering and computer science?
Computer Science Software Engineeringis concerned with
Computer science theories are currently insufficient to act as a complete base for software engineering,
BUT it is a foundation for practical aspects of software engineering
theory fundamentals
the practicalities of developing delivering useful software
6
What is the difference between software engineering and system engineering? Software engineering is part of System
engineering System engineering is concerned with all aspects
of computer-based systems development including hardware, software and process engineering
System engineers are involved in system specification, architectural design, integration and deployment
7
What Is Software?
Computer software is the product that
software professionals design and build.
It encompassesProgramsContentDocuments
8
Who Does It? Software engineers build it.Virtually everyone in the industrialized world usesit either directly or indirectly.
Why Is It Important? Software affects nearly every aspect of our lives.
What Are The Steps? You build software like you build any successfulproduct, by applying a process that leads to a high-quality result.
9
What Is the Work Product?
From the view point of a software engineer, the
work product is the programs, documents, and
content (data).
From the user’s viewpoint, the work product is the
resultant information that somehow makes the
user’s world better.
10
1.1 The Evolving Role of Software
Software takes on a dual role: A productDelivers the computing potential embodied bycomputer hardware
The vehicle for delivering a productActs as the basis for the control of the computer
(OS), the communication of information (networks), and the creation and control of other programs (software tools and environments)
The most important product: Information.
11
Software-Related Problems
Scenario: The widespread use of computers has made society increasingly dependent on reliable operation of software.
Consequence: Enormous economic damage and potential human suffering can occur when software fails.
Our Objective: build computer software that has high reliability and quality.
Threats: Our ability to support and enhance existing programs is threatened by poor design and inadequate resources.
12
An Industry Perspective
In the early days of computing, computer-based
system were developed using hardware-oriented
management.
Project managers focused on hardware.
Project managers applied the controls, methods,
and tools that we recognize as hardware
engineering.
13
In the early days ...
In the early days, programming was viewed as
an “art form.”
The programmer often learned his/her craft by
trial and error.
The software world was virtually undisciplined.
14
Today ...
Today, the distribution of costs for the
development of computer-based systems has
changed dramatically.
Software, rather than hardware, is the largest single cost item.
15
Questions
For almost two decades managers and many technical practitioners have asked the following
questions: Why does it take so long to get programs finished ? Why are development costs so high ? Why can’t we find all errors before we give the
software to our customers? Why do we continue to have difficulty in measuring
progress as software is being developed?
16
SOFTWARE:-
Definition of Software may take the following form:
(1) Instructions (computer programs) that
when executed provide desired function
and performance,
(2) Data (contents) that enable the programs to
Adequately manipulate information, and
(3) Documents that describe the operation and use
of the programs.
17
Software Characteristics:
Software does not wear out.
Useful life phase
Wear out
phase
Burn-inphase
Fai
lure
Int
ensi
ty
Time
18
Software is not manufactured but developed or engineered
Software Characteristics:
Reusability of components
Software is flexible
19
Comparison of constructing a bridge vis-à-vis writing a program.
Sr.No
Constructing a bridge Writing a program
1.
2.
3.
4.
5.
6.
7.
Software Characteristics:
The problem is well understood Only some parts of the problem are understood, others are not
There are many existing bridges
The requirement for a bridge typically do not change much during constructionThe strength and stability of a bridge can be calculated with reasonable precisionWhen a bridge collapses, there is a detailed investigation and report
Engineers have been constructing bridges for thousands of years
Materials (wood, stone,iron, steel) and techniques (making joints in wood, carving stone, casting iron) change slowly.
Every program is different and designed for special applications.Requirements typically change during all phases of development.Not possible to calculate correctness of a program with existing methods.
When a program fails, the reasons are often unavailable or even deliberately concealed.Developers have been writing programs for 50 years or so.
Hardware and software changes rapidly.
20
SystemSoftware
Real Time Software
Embedded Software
Engineering and Scientific
Software
Web basedSoftware
Artificial Intelligence
SoftwarePersonal
Computer Software
BusinessSoftware
1.3 The Changing Nature of Software
21
The Changing Nature of Software
Trend has emerged to provide source code to the customer and organizations.
Software where source codes are available are known as open source software.
Examples
Open source software: LINUX, MySQL, PHP, Open office, Apache webserver etc.
22
The Change Nature of SW
New Challenges Ubiquitous computing- information processing has been
thoroughly integrated into everyday objects and activities.
Netsourcing- Outsourcing applications that run on the Web. Since the browser provides universal access to Web content and applications, an application can run on a third-party Web server as
easily as it can on an internal Web server (intranet)
Opensource
23
Software Myths
Unlike ancient myths, software myths
propagates misinformation and confusion
that have caused serious problems for
managers, technical people, and customers.
24
Management Myths :-
Myth:-We already have a book that’s full of standardsand procedures for building software. Won’t that provide my people with everything they need to know?
Reality:-The book of standards may very well exist, but is it used? Is it complete? In many cases, the answer is no.
25
Myth:-
If we get behind schedule, we can add more
Programmers and catch up.
Reality:-
Software development is not a mechanistic
Process like manufacturing. “Adding people to a
late software project makes it later.”
26
Myth:-If I decide to outsource the software project to a third party, I can just relax and let thatfirm build it.
Reality:-If an organization does not understand how to manage and control software projectsInternally, it will invariably struggle when itout-sources software projects.
27
A general statement of objectives is sufficient to get started with the development of software. Missing/vague requirements can easily be incorporated/detailed out as they get concretized.
If we do so, we are heading towards a disaster.
Software Myths (Customer Perspectives)
28
Myth:-
Project requirements continually change,
but change can be easily accommodated
because software is flexible.
Reality:-
It is true that software requirements do change, but the impact of change varies with the time at which it is introduced.
29
Practitioner’s (Developer’s) Myths:-
Myth:-Once we write the program and get it to work, our job is
done.
Reality:-“The sooner you begin writing code, the longer it’ll take
you to get done.”
Industry data indicate that between 60 and 80% of all effort expended on software will be expended after it is delivered to the customer for the first time.
30
Myth:-Until I get the program running, I have no way of a
assessing its quality.
Reality:-
One of the most effective software quality
assurance mechanisms can be applied from the
Inception of a project- the formal technical reviews.
31
Myth:-The only deliverable work product for a successful project is the working program.
Reality:-A working program is only one part of a software configuration that includes many elements.
Documentation provides a foundation for successful engineering and, more importantly, guidance for software support.
32
Myth:-Software engineering will make us createvoluminous and unnecessary documentationand will invariably slow us down.
Reality:-Software engineering is not about creating
documents. It is about creating quality. Better quality leads to reduced network. And reduced rework results in faster delivery times.
CHAPTER-2
A GENERIC VIEW OF PROCESS
Chapter Overview
• What? A software process – a series of predictable steps that leads to a timely, high-quality product.
• Who? Managers, software engineers, and customers.
• Why? Provides stability, control, and organization to an otherwise chaotic activity.
• Steps? A handful of activities are common to all software processes, details vary.
• Work product? Programs, documents, and data.• Correct process? Assessment, quality deliverable.
2.1 Software Engineering-A Layered Technology
a “quality” focusa “quality” focus
process modelprocess model
methodsmethods
toolstools
QUALITY:-
Any engineering approach must rest on an
Organizational commitment to quality.
The bedrock that supports software engineering is
a quality focus.
PROCESS:- It defines a frame work that must be established for effective
delivery of software engineering technology.
This framework is for a set of key process areas (KPAs)
It forms the basis for management control of software projects and establishes the context in which (tmwqc) technical methods are applied, milestones are established, work products (documents, models, data, reports, forms,
etc.) are produced, quality is ensured and change is properly managed.
Process defines “what to” establish in a context.
METHODS:-
S/W engineering methods provide the technical “how to’ s” for building s/w.
Methods encompass a broad array of tasks
that include communication, requirements analysis, design modeling, program construction, testing and support.
Methods defines “how to” establish the “what to’s” stated in the process.
Tools:-
Software technology tools provide automated or semi-automated support for the process and the methods.
When tools are integrated so that information created by one tool can be used by another, a system for the software development, called Computer-Aided Software Engineering (CASE) is
established.
2.2 A Process Frame Work
It’s a set of guidelines, concepts and best practices that describes high level processes in SE.
A Process framework establishes the foundation
for a complete software process identifying a small
number of framework activities that are applicable
to all software projects, regardless of their size or
complexity.
Ex: Eclipse Process Framework, Microsoft Solutions Framework.
A Common Process Framework
The process framework encompasses a set of Umbrella activities that are applicable across the entire software process (irrespective of SDLC stages)
The following generic (common) process framework activities are applicable to the vast majority of software projects:
Activity Objective
Communication customer collaboration and requirements gathering
Planning establishes engineering work plan, describes technical risks, lists resource requirements, work products produced, and defines work schedule
Modeling creation of models to help developers and customers understand the requirements and software design
Construction code generation and testing
Deployment software delivered for customer evaluation and feedback
Umbrella Activities
1. Software project management (SPM)
2. Formal technical reviews (FTR)
3. Software quality assurance (SQA)
4. Software configuration management (SCM)
5. Document preparation and production
6. Reusability management (Ru.M)
7. Measurement
8. Risk management (RM)
Attributes for Comparing Process Models
1.Overall flow of activities and tasks.
2.Degree to which works tasks are defined within each frame work.
3.Degree to which work product identified and required.
4.Manner of applying quality assurance.
5.Process description degree.
6.Level of autonomy (uncentralization) given to the software project team.
7.Degree of involving customer and stakeholders in project.
8.Degree to which team organization &roles are prescribed.
2.3 Capability Maturity Model Integration
(CMMI)
Definition : Capability Maturity Model Integration (CMMI) is a process improvement approach that helps organizations improve their performance.
Capability levels
1. Level 0: Incomplete (Ad-hoc)
2. Level 1: Performed (Repeatable)
3. Level 2: Managed
4. Level 3: Defined
5. Level 4: Quantitatively managed
6. Level 5: Optimized
CMMI Staged Representation - 5 Maturity Levels
Level 5
Initial
Level 1
Processes are unpredictable, poorly controlled, reactive.
Managed
Level 2
Processes are planned, documented, performed, monitored, and controlled at the project level. Often reactive.
Defined
Level 3 Processes are well characterized and understood. Processes, standards, procedures, tools, etc. are defined at the organizational (Organization X ) level. Proactive.
Quantitatively Managed
Level 4
Processes are controlled using statistical and other quantitative techniques.
Optimizing
Proce
ss M
atur
ity
Process performance continually improved through incremental and innovative technological improvements.
Key Process Areas (KPAs) for Development Model
Maturity Level 2 - Managed CM - Configuration Management MA - Measurement and Analysis PMC - Project Monitoring and
Control PP - Project Planning PPQA - Process and Product Quality
Assurance REQM - Requirements Management SAM - Supplier Agreement
Management
Maturity Level 3 - Defined DAR - Decision Analysis and
Resolution IPM - Integrated Project
Management OPD - Organizational Process
Definition OPF - Organizational Process Focus OT - Organizational Training
Management
6. PI - Product Integration 7. RD - Requirements
Development 8. RSKM - Risk Management 9. TS - Technical Solution 10. VAL - Validation 11. VER - Verification
Maturity Level 4 - Quantitatively Managed
OPP - Organizational Process Performance
QPM - Quantitative Project Management
Maturity Level 5 - Optimizing CAR - Causal Analysis and
Resolution OPM - Organizational
Performance Management
Capability levels:-
Level 0: Incomplete.
The Process area is either not performed or does not achieve all goals and objectives defined by the CMMI for level 1 capability.
Level 1: Performed. (Initial=Incomplete + Performed)
All of the specific goals of the process area have been satisfied. Work tasks required to produce defined work production are being conducted.
Level 2: Managed.1. All work associated with the process area conforms to
an organizationally defined policy;
2. All people doing the work have access to adequate
resources to get the job done;
3. Stakeholders are actively involved in the process
area as required;
4. All work tasks and work products are “monitored, controlled, and reviewed;
Level 3: Defined.
The process is “tailored from the organization’s set
of standard processes according to the
organization’s tailoring guidelines, and contributes
work products, measures, and other
process-improvement information to the
organizational process assets” .
Level 4: Quantitatively managed.
“Quantitative objectives for quality and
process performance are established and
used as criteria in managing the process”.
Level 5: Optimized.
The process area is adapted and optimized using
quantitative means to meet changing customer
needs and to continually improve the efficacy of
the process area under consideration.
Behaviors at the Five Levels
Initial
Managed
Defined
QuantitativelyManaged
Optimizing
Process is unpredictable,poorly controlled, and reactive
Process is characterized for projects and is oftenreactive
Process is characterizedfor the organization andis proactive
Process is measuredand controlled
Focus is on continuousquantitative improvement
Maturity Level Process Characteristics Behaviors
Focus on "fire prevention";improvement anticipated anddesired, and impacts assessed.
Greater sense of teamwork and inter-dependencies
Reliance on defined process. People understand, support and follow the process.
Over reliance on experience of goodpeople – when they go, the processgoes. “Heroics.”
Focus on "fire fighting";effectiveness low – frustration high.
Key Process Areas (KPAs)
The SEI has associated KPAs with each maturity levels.
The CMMI defines each process area in terms of “specific goals” and the “specific practices” required to achieve these goals.
Specific goals establish the characteristics that must exist if the activities implied by a process area are to be effective.
Specific practices refine a goal into a set of process-related activities.
CMMI Terminology & Structure
Maturity Levels (1 - 5)
GenericPractices
GenericGoals
Process Area 2
Common Features
Process Area 1 Process Area n
VerifyingImplementation
SpecificGoals
SpecificPractices
Abilityto Perform
DirectingImplementation
RequiredRequired
Sub practices, typical work products, discipline amplifications, generic practice elaborations, goal and
practice titles, goal and practice notes, and references
Commitmentto Perform
Sub practices, typical work products, discipline amplifications, generic practice elaborations, goal and
practice titles, goal and practice notes, and references
Informativ
eInformative
Required. Specific for each process area.
Required. Common across all process areas.
CMMI Components Within each of the 5 Maturity Levels, there are basic
functions that need to be performed – these are called Process Areas (PAs). For Maturity Level 2 there are 7 Process Areas that must be
completely satisfied. For Maturity Level 3 there are 11 Process Areas that must be
completely satisfied. Given the interactions and overlap, it becomes more efficient to
work the Maturity Level 2 and 3 issues concurrently. Within each PA there are Goals to be achieved and within each
Goal there are Practices, work products, etc. to be followed that will support each of the Goals.
The specific goals (SG) and specific practices (SP)
defined for project planning are:-
SG 1: Establish estimates
SP: 1. Estimate the scope of the project
2.Establish estimates of work product and
task attributes.
3. Define project life cycle.
4. Determine estimates of effort and cost.
SG 2: Develop a project plan
SP: 1. Establish the budget and schedule
2. Identify project risks
3. Plan for data management.
4. Plan for project resources.
5. Plan for needed knowledge and
skills.
6. Plane stakeholder involvement.
7. Establish the project plan.
SG 3: Obtain commitment to the plan
SP: 1. Review plans that affect the
project.
2. Reconcile work and resource levels.
3. Obtain plan commitment.
The Generic goals (GG) and practices (GP) for the
project planning process area are:
GG 1: Achieve specific goals
GP: 1. Perform base practices.
GG 2: Institutionalize a managed process
GP: 1. Establish an organizational policy
2. Plan the process.
3. Provide resources.
4. Assign responsibility.
5. Train people.
6. Manage configurations.
7. Identify and involve relevant
stakeholders.
8. Monitor and control the process.
9. Objectively evaluate adherence.
10. Review status with higher level
management.
GG 3: Institutionalize a defined process
GP: 1. Establish a defined process.
2. Collect improvement information.
GG 4: Institutionalize a quantitatively managed process.
GP: 1. Establish quantitative objectives for the
project.
2. Stabilize subprocess performance.
GG 5: Institutionalize a Optimizing process.
GP: 1. Ensure continuous process
improvement.
2. Correct root cause of problems.
2.4 Process Patterns Process Patterns define a set of activities, actions, work
task , work products and /or related behaviours.
Templates or methods for describing important characteristics of software processes .
Examples:- Customer Communication( Process activity ) Analysis( An action ) Requirement gathering( Process task ) Design model ( Work Product ) Software teams can combine software patterns to
construct processes that best meet the needs of specific projects
Generic software pattern elements :-Pattern Name Intent (objective of pattern) Type
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
Initial context (describes conditions that must be present prior to using pattern)
Problem (The Problem to be solved by the pattern is described).
Solution (describes how to implement pattern correctly)
Resulting context (describes conditions that result when pattern has been implemented successfully)
Related patterns (links to patterns directly related)
Known uses/examples (instances in which pattern is applicable)
2.5 Process Assessment
The Process should be assessed to ensure that it meets a set of basic process criteria that have been shown to be essential for a successful software engineering. Many different assessment option are available.-SCAMPI-CBA IPI-SPICE-ISO 9001:2000
Standard CMMI Assessment Method for
Process Improvement (SCAMPI):-It provides a five-step process assessment model
that incorporates initiating, diagnosing, acting,
establishing learning.
CMM-Based Appraisal for Internal Process
Improvement (CBA IPI):-Provides a diagnostic technique for assessing the
relative maturity of a software organization.
SPICE (ISO/IE15504):-SPICE (ISO/IE15504) standard defines a set of
requirements for process assessment
ISO 9001:2000:-ISO 9001:2000 for Software defines
requirements for a quality management system that will produce higher quality products and improve customer satisfaction
Assessment and Improvement
Software Process
Software ProcessAssessment
Software ProcessImprovement
CapabilityDetermination
Is examined by
Identifies capabilities and risk of
Leads toLeads to
Motivates
Identifies
Modifications to
2.6 Personal and Team Process Models
1. Personal Software Process (PSP):-
The Personal Software Process (PSP)
emphasizes personal measurement of both the
work product that is produced and the resultant
Quality of the work product .
What is PSP?The Personal Software Process shows engineers how to
1. Manage the quality of their projects. 2. Make commitments they can meet. 3. Improve Estimating and Planning. 4. Reduce defects in their products.
The PSP can be used by engineers as a guide to a disciplined and structured approach to developing software.
The PSP can be applied to many parts of the
software development process, including small-program development requirement definition document writing systems tests systems maintenance
enhancement of large software systems
The PSP process model defines the five
framework activities:
1. Planning:- This activity isolates requirements.
2. High-Level Design:-External Specifications.
3. High-Level Design Review:-Formal verification.
4. Development:- The component level design.
5. Postmortem:- The effectiveness of the process is determined.
2. Team Software Process (TSP):-
The goal of TSP is to build a “Self-Directed”
Project team that organizes itself to produce high-
quality software.
What is TSP?The Team Software Process (TSP), along
with the Personal Software Process (PSP),
helps the high-performance engineer to Ensure quality software products Create secure software products Improve process management in an
organization
Objectives of TSP:- Build self-directed teams that plan and track their work,
establish goals, and own their processes and plans
Show managers how to coach and motivate their teams and maintain peak performance
Accelerate software process improvement by making Level 5 behavior normal and expected
Provide improvement guidance to high-maturity organizations
Facilitate university teaching of industrial team skills
TSP defines the following framework activities: 1. Launch
2. High-Level Design
3. Implementation
4. Integration and test
5. Postmortem.
Each project is “launched” using a sequence of tasks
To establish a solid basis for starting the project.
Review project objectives with management and agree on and document team goals.
Establish team roles. Define the team’s development process. Make a quality plan and set quality targets. Plan for the needed support facilities. Make a development plan for the entire project.
Make detailed plans for each engineer for the next phase.
Merge the individual plans into a team plan. Rebalance team workload to achieve a minimum
overall schedule. Assess project risks and assign tracking
responsibility for each key risk.
PROCESS MODELS
Overview
Prescriptive process models prescribe a distinct set of activities, actions, tasks, milestones, and work products required to engineer high quality software.
Prescriptive software process models are adapted to meet the needs of software engineers and managers for a specific project.
Prescriptive software models provide stability, control, and organization to a process that if not managed can easily get out of control.
Framework activities for a particular process model may be organized into a process flow that may be linear, incremental, or evolutionary.
The software engineer's work products (programs, documentation, data) are produced as a consequence of the activities defined by the software process.
The best indicators of how well a software process has worked are the quality, timeliness, and long-term viability of the resulting software product.
Prescriptive Models
Originally proposed to bring order to the chaos of software development.
They provide reasonable guidance to software teams.
Yet, they have not provided a definitive answer to the problems of software development in an ever changing computing environment.
The Waterfall Model
When the requirements of a problem are reasonably well understood- when work flows are reasonably linear fashion.
It may also occur in a limited number of new development efforts, but only when requirements are well defined and reasonably stable.
The Waterfall model, is also called the Classic life cycle, a systematic sequential approach to s/w developments that begins with customer specification of requirements and progresses through planning, modeling, construction, and deployment.
The Waterfall model is the oldest paradigm for s/w engineering.
The Waterfall Model:-
Communication
Planning
Modeling
Construction
Deployment
Advantages of Waterfall Model
1. Easy to understand and implement.2. Widely used and known (in theory!).3. Reinforces good habits: define-before- design, design-before- code.4. Identifies deliverables and milestones5. Works well on mature products and weak teams.6.Testing is inherent to every phase of the waterfall model.7. It is an enforced disciplined approach8. It is documentation driven, that is, documentation is produced at every stage.
Problems or Disadvantages of Waterfall Model
1. Real projects rarely follow the sequential flow that the model proposes.
2. It is often difficult for the customer to state all requirements explicitly.
3. The customer must have patience. A working version of the programs will not be available until
late in the project time-span.
The linear nature of the waterfall model leads to “blocking states” .
Incremental Process Model
The Incremental Model
The RAD Model (Rapid Application Development)
The Incremental Model
COM
PLMOD
CONDEP
COM
PL
MOD
CON
DEP
COM
PL
MOD
CON
DEP
INCREMENT-1
INCREMENT-2
INCREMENT-N
The Incremental Model
The Incremental model combines elements of the waterfall model applied in an iterative fashion.
Each Linear sequences produces deliverable “increments” of the software.
The incremental process model is iterative in nature.
Early increments are “Stripped down” versions of the final product.
Incremental development is particularly useful when Staffing is unavailable.
Early increments can be implemented with fewer people.
Rapid Application Development
Similar to waterfall but uses a very short development cycle (60 to 90 days to completion).
Uses component-based construction and emphasises reuse and code generation.
Use multiple teams.
Requires heavy resources.
Requires developers and customers who are heavily committed.
Rapid Application Development
com
Plan
Mod
Con
Mod
Con
Mod
Con
Dep
60-90 days
Team# 1
Team # 2
Team #n
The RAD approach maps into the generic framework activities:-
Communication
- The business problem
- information characteristicsPlanningModeling
-Business Modeling
-Data Modeling
-Process Modeling
Construction
-Component reuse
-Automatic Code generation
-TestingDeployment
-Integration
-Delivery
-Feedback
Drawbacks of RAD Model:-
1. For large, but scalable projects.2. If Developers and customers are not
committed , project fails.3. If a system cannot be properly modularized, building the components necessary for RAD
will be problematic.4. If high performance is an issue, RAD approach
may not work.5. RAD may not be appropriate when technical risks are high.
3.4 Evolutionary Process Model
S/w engineers need a process model that has been explicitly designed to accommodate a product that evolves over time.
Evolutionary models are Iterative.
They are characterized in a manner that enables software engineers to develop increasingly more complete versions of the software.
1. Prototyping:-
Specifying requirements is often very difficult. Users don’t know exactly what they want until
they see it. Prototyping involves building a mock-up of the
system and using to obtain for user feedback. Mechanism for identifying requirements. Users like the method, get a feeling for the
actual system.
Prototyping:-
Quick Plan
Communication ModelingQuick Design
Deployment Delivery& Feedback
Construction of prototype
2. The Spiral Model :-
A different approach born of the evolution of the waterfall model.
The Spiral model, originally proposed by Boehm , is an evolutionary s/w process model that couples the iterative nature of prototyping.
More complete versions of the s/w. S/w is developed in a series of evolutionary
releases.
During early iterations- a paper model or prototype.
During later iterations - complete versions are produced.
Spiral Model :-
communication
planning
modeling
constructiondeployment delivery feedback
start
analysis design
code test
estimation scheduling risk analysis
A Spiral model is divided into a set of frame work activities defined by the s/w engineering team.
Risk is considered as each revolution is made.
Process is represented as a spiral rather than as a sequence of activities with Backtracking.
Anchor point milestones- are noted for each revolutionary pass.
Unlike other process model , the spiral model can be adapted to apply throughout the life of the computer s/w.
The first circuit around the spiral might represents a “Concept development project” at core of the spiral.
In later iterations- “new product development project” commences.
Still later iterations – “product enhancement project”.
Whenever a change is initiated, the process starts at that appropriate entry point. Example: product enhancement.
Realistic approach to the development of large-scale system.
Difficult to convince customer.
3. Concurrent Development Model
The concurrent development model, sometimes called concurrent engineering, can be represented schematically as a series of frame work activities.
The activity-modeling- may be in any one of the states noted at any given time. Similarly, other activities or tasks can be represented in an analogous manner.
Example: Communication or construction All activities exist concurrently but reside in
different states.
Concurrent Development Model
Under review
Baselined
Done
Under
revision
Awaiting
changes
Under
development
none
Modeling activity
represents the stateof a software engineeringactivity or task
The Concurrent process model is applicable to all types of s/w development and provides an accurate picture of the current state of the project.
3.5 Specialized Process Models
Special Process models take on many of the characteristics of one or more of the conventional models.
1. Component – Based Development
2. Formal Method Model
3. Aspect – Oriented Software Development
1. Component – Based Development
Commercial off-the shelf (COTS) s/w components, can be used when s/w is to be built.
The Component – based development model incorporates many of the characteristics of the spiral model.
It is evolutionary in nature , iterative approach to the creation of s/w.
Modeling and construction activities begin with the identification of candidate components.
The component – based development model incorporates the following steps:-
Available component-based products are researched and evaluated for the application domain in question.
1. Component integration issues are considered.2. A Software architecture is designed to
accommodate the components. 3. Component are integrated into the architecture.4. Comprehensive testing is conducted to ensure
proper functionality.
The Component – based development models leads to software reuse and a number of measurable benefits.
2. The Formal Methods Model
The formal methods model encompasses a set of activities that leads to formal mathematical specifications of computer s/w.
Formal methods model provide a mechanism, for eliminating many of the problems that are difficult to overcome using other s/w engineering paradigms.
Ambiguity, incompleteness and inconsistency can be discovered and corrected more easily.
Offers Defect-free software.
The formal methods model are not widely used due to :-
1. The development of formal model is currently quite time-consuming and expensive.
2. Because few s/w developers have the necessary background to apply formal methods, extensive training is required.
3. It is difficult to use the models as a communication mechanism for technically
unsophisticated customers.
3.6 The Unified Process
Unified Process —a “use-case driven, architecture-centric, iterative and incremental” software process closely aligned with the Unified Modeling Language (UML)
Phases of the Unified Process
software increment
Release
Inception
Elaboration
construction
transition
production
The Inception Phase of the UP encompasses both customer communication and planning activities.
Business requirements, rough architecture, plan for the iteration, incremental nature of the ensuring projects is developed by using Use-cases
Use-cases help to identify the scope and basis for the project planning.
Planning identifies resources, assesses major risks, defines a schedule and establishes a basis for the phases.
The Elaboration phase encompasses the customer communication and modeling activities of the generic process model.
Elaboration refines and expands the preliminary use-cases and expands the architectural representation to include five different views of the s/w –
the use-case model, the analysis model, the design model, the implementation model, the deployment model.
Elaboration creates an “executable architectural baseline”.
The Construction phase of the Unified Process-
Using the architectural model as input, the construction phase develops or acquires the software components that will make each use-case operational for end-user.
Tests are conducted.
The Transition Phase of the Unified Process- Software is given to end-users for beta testing,
and user feedback reports both the defects and necessary changes.
The s/w team creates necessary support information.
Example: User manuals, trouble shooting guides and installation procedures.
The five UP phases do not occur in a sequence, but rather with staggered concurrency.
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
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
Construction phase Design model Software components Integrated software increment Test plan Test cases Support documentation (user, installation,
increment)
Transition phase Delivered software increment Beta test reports User feedback
Software Engineering Why should we take a course on that?
Motivation
Software can have a hugeimpact in any aspect of society.
Importance of software
Where can you find software?
Some popular ones…
Some popular ones…
Some popular ones…
And even in…
Conclusion
Software is Almost Everywhere.
Problems in software development
•The final Software doesn´t fulfill the needs of the customer.
•Hard to extend and improve: if you want to add a functionality later is mission impossible.
•Bad documentation.
•Bad quality: frequent errors, hard to use, ...
•More time and costs than expected
Common issues
But
That never happens,
right?
Wrong!
Ariane 5 Flight 501
Cause: design errors in the software
Chaos Report
It is not enough to do your best: you must Know what to do, and THEN do your best.-- W. Edwards Deming
Conclusion
Programming is NOT enough!
And Since…
A clever person solves a problem. A wise person avoids it.- Albert Einstein
Solution
Software Engineering
The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software. -Wikipedia
What is it?
???
Software Engineering
The study and application of methodologies to develop quality software that fulfill customer needs.
What is it?
Software EngineeringObjetive
To produce software that is:
• On time: is deliver at the established date.
• Reliable: doesn´t crash.
• Complete: good documentation, fulfill customer needs.
The team
Stages for software development
Requirements Analysis
Software Design
Implementation
Testing
Maintenance
1. Requirements Analysis
Find out what the client want the software to do
2. Design
Planning the software solution
3. Implementation
Code!!!
4. Testing
Executing the application trying to find software bugs
5. Maintenance
Any activity oriented to change an existing software product.
References
•http://upload.wikimedia.org/wikipedia/commons/thumb/a/a2/Avianca_767-200_at_El_Dorado.JPG/800px-Avianca_767-200_at_El_Dorado.JPG •http://www.nosoloviajeros.com/imagenes/colombia/transmilenio.jpg •http://files.nireblog.com/blogs1/keniecita/files/celular-2.jpg •http://www.fayerwayer.com/up/2008/06/iphone3g.jpg •http://www.slideshare.net/soreygarcia/ingenieria-de-software-para-dummies •http://www.projectsmart.co.uk/docs/chaos-report.pdf •http://www.evilaliens.com/images/software_engineering_explained.gif•http://sunnyday.mit.edu/accidents/Ariane5accidentreport.html•http://stackoverflow.com/questions/84556/whats-your-favorite-programmer-cartoon •http://stuffthathappens.com/blog/2008/03/05/simplicity/•http://www.troyangrignon.com/dilbertsoftwarerequirements.jpg•http://www.phdcomics.com/comics/archive/phd120804s.gif•http://www.phdcomics.com/comics/archive/phd011406s.gif