SE Unit1
SE Unit1
me/jntuh
Characteristics of Software
Software Engineering
Definition:
The systematic, disciplined, quantifiable approach to the development,
operation, and maintenance of software.
Components:
Application of engineering to software.
Study of various approaches.
Historical Perspectives
1990s
Mid-1990s
Later 1990s
2000s
Present Day
A huge software industry has become a dominant factor in the economies of the
industrialized world.
1. System Software
Definition:
Collection of programs written to service other programs.
Characteristics:
Heavy interaction with computer hardware.
Heavy usage by multiple users.
Concurrent operation requiring scheduling, resource sharing, and
sophisticated process management.
Complex data structures and multiple external interfaces.
Examples:
Compilers, editors, and file management utilities.
2. Application Software
Definition:
Standalone programs solving specific business needs.
Characteristics:
Facilitates business operations or management/technical decision making.
Used to control business functions in real-time.
Examples:
Point-of-sale transaction processing, real-time manufacturing process
control.
3. Engineering/Scientific Software
Definition:
Applications ranging from astronomy to volcanology.
Examples:
Computer-aided design, system simulation, and other interactive
applications.
4. Embedded Software
Definition:
Resides within a product or system, used to implement and control features
and functions.
Examples:
Digital functions in automobiles, dashboard displays, braking systems, etc.
5. Product-line Software
Definition:
Designed to provide a specific capability for use by many different
customers.
Examples:
Word processing, spreadsheets, computer graphics, multimedia,
entertainment, database management, personal and business financial
applications.
6. Web-Applications
Definition:
Evolving into sophisticated computing environments integrated with
corporate databases and business applications.
Definition:
Makes use of nonnumerical algorithms to solve complex problems.
Applications:
Robotics, expert systems, pattern recognition, artificial neural networks,
theorem proving, and game playing.
1. Ubiquitous Computing:
Develop systems and application software for communication across vast
networks involving small devices, personal computers, and enterprise
systems.
2. Netsourcing:
Architect simple and sophisticated applications providing benefits to
targeted end-user markets worldwide.
3. Open Source:
Build self-descriptive source code and develop techniques for customers and
developers to track changes within the software.
Software Myths
Beliefs about software and the process used to build it can be traced to the earliest
days of computing. These myths have several attributes that make them insidious.
Management Myths
Myth: We already have a book that‘s full of standards and procedures for
building software - Won't that provide my people with everything they need
to know?
Reality:
The book of standards may exist, but its effectiveness depends on its use and
awareness.
It needs to reflect modern software engineering practices to be beneficial.
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 more people requires time for education, reducing productive
development effort.
People can be added, but in a planned and well-coordinated manner.
Myth: If I decide to outsource the software project to a third party, I can just
relax and let that firm build it.
Reality:
If an organization lacks internal software project management capabilities,
outsourcing can lead to struggles.
Customer Myths
Reality:
Ambiguous objectives are a recipe for disaster.
Reality:
Change impact varies, and it can require additional resources and major
design modifications.
Practitioner’s Myths
Myth: Once we write the program and get it to work, our jobs are done.
Reality:
Effort after the software is delivered is substantial (60-80%).
Completion of the working program is just one part of the software
configuration.
Myth: The only deliverable work product for a successful project is the
working program.
Reality:
A working program is part of a software configuration, which includes
documentation for software support.
Reality:
Software engineering is about creating quality, not just documents.
Better quality reduces rework and leads to faster delivery times.
1. Tools
2. Methods
3. Process
4. A Quality Focus
1. Process Layer
The process layer is the foundation for software engineering. It serves as the glue
that holds the technology layers together. The software engineering process is a
framework established for the effective delivery of software engineering
technology.
2. Software Layer
The software layer forms the basis for management control of software projects. It
establishes the context in which:
3. Methods Layer
Communication.
Requirements analysis.
Design modeling.
Program construction.
Testing and support.
4. Tools Layer
The integration of tools ensures that information created by one tool can be
seamlessly used by another, enhancing efficiency and collaboration in software
development.
A Process Framework
A Process Framework
A PROCESS FRAMEWORK
A software process must be established for the effective delivery of software
engineering technology. The process framework lays the foundation for a complete
software process, identifying a small number of framework activities applicable to
all software projects, regardless of size or complexity.
a process defines "who is doing what, when, and how to reach a certain goal."
Communication Activity
Planning Activity
Modeling Activity
Analysis Action
Requirements Gathering Work Task
Elaboration Work Task
Negotiation Work Task
Specification Work Task
Validation Work Task
Design Action
Data Design Work Task
Architectural Design Work Task
Interface Design Work Task
Component-Level Design Work Task
Construction Activity
Deployment Activity
Planning
Overview:
Establishes a plan for the software engineering work.
Describes:
Technical tasks to be conducted.
Risks likely to be encountered.
Resources required.
Work products to be produced.
Work schedule.
Modeling
Overview:
Encompasses the creation of models for better understanding of software
requirements and design.
Composed of two software engineering actions:
Analysis:
Involves a set of work tasks focused on understanding
requirements.
Design:
Involves work tasks to create a design model.
Construction
Overview:
Combines core generation and testing.
Core generation involves creating the actual code.
Testing is required to uncover errors in the code.
Deployment
Overview:
Software is delivered to the customer.
Customer evaluates the delivered product.
Provides feedback based on the product's evolution.
Umbrella Activities
A set of umbrella activities plays a crucial role in the software process, providing
overarching support:
Capability Levels:
Level 0: Incomplete
The process area is either not performed or does not achieve all goals and
objectives defined by CMMI for level 1 capability.
Level 1: Performed
Level 2: Managed
Level 3: Defined
Level 5: Optimized
Note: Each level represents a maturity stage, and achieving higher levels indicates a
more mature and optimized organizational process.
The CMMI defines each process area in terms of "specific goals" and the "specific
practices" required to achieve these goals. Specific practices refine a goal into a set
of process-related activities.
SG 1 Establish estimates:
SP 1.1 Estimate the scope of the project.
SP 1.2 Establish estimates of work product and task attributes.
SP 1.3 Define project life cycle.
SP 1.4 Determine estimates of effort and cost.
SG 2 Develop a Project Plan:
SP 2.1 Establish the budget and schedule.
SP 2.2 Identify project risks.
SP 2.3 Plan for data management.
SP 2.4 Plan for needed knowledge and skills.
SP 2.5 Plan stakeholder involvement.
Note: Achieving these generic goals is essential for progressing through the
capability levels.
PROCESS PATTERNS
The software process can be defined as a collection of patterns that define a set of
activities, actions, work tasks, work products, and/or related behaviors required to
develop computer software.
PROCESS ASSESSMENT
The existence of a software process is no guarantee that software will be delivered
on time, meet customer needs, or exhibit the technical characteristics leading to
long-term quality. Additionally, assessing the process itself is essential to ensure it
meets basic criteria for successful software engineering.
Software Capability
Motivation: Identifies capabilities and risks.
Lead: Software Lead.
PSP emphasizes personal measurement of work product and resultant quality. The
process model includes:
1. Planning:
Isolates requirements, develops size and resource estimates, and makes
defect estimates.
Identifies development tasks and creates a project schedule.
2. High-Level Design:
Develops external specifications for components, creates component
designs.
Prototypes built when uncertainty exists.
3. High-Level Design Review:
Applies formal verification methods to uncover errors in the design.
Maintains metrics for all important tasks and work results.
4. Development:
TSP aims to build self-directed project teams that organize themselves to produce
high-quality software. Objectives include:
Building self-directed teams that plan and track their work, establish goals, and
own their processes and plans.
Coaching and motivating teams to sustain peak performance.
Accelerating software process improvement, making CMM level 5 behavior
normal and expected.
TSP utilizes scripts, forms, and standards to guide team members. Scripts define
specific process activities and detailed work functions.
Process Models
The Waterfall Model Process Models > THE WATERFALL
MODEL
Spiral Model Process Models > THE SPIRAL MODEL
Agile Methodology Process Models > Agile Process Model
Process Models
PROCESS MODELS
Prescriptive process models define a set of activities, actions, tasks, milestones, and
work products required for engineering high-quality software. Although not perfect,
these models offer a useful roadmap for software engineering work. A prescriptive
process model populates a process framework with explicit task sets for software
engineering actions.
Context:
Advantage:
Challenges:
1. Sequential Flow: Real projects rarely follow the sequential flow proposed by
the model. While it can accommodate iteration, it does so indirectly, leading to
potential confusion as changes occur.
2. Requirement Understanding: Difficulty in explicitly stating all requirements.
The model struggles to accommodate the natural uncertainty present at the
beginning of many projects.
3. Customer Patience: The customer needs patience as a working version of the
software is not available until late in the project time-span. If a major error is
undetected, it can be disastrous until the program is reviewed.
The waterfall model's rigidity in handling changes and the need for explicit
requirements make it less suitable for dynamic and uncertain project environments.
Key Features:
Context:
Advantages:
Drawbacks:
Requirements Gathering:
In this phase, you must define the requirements. You should explain business
opportunities and plan the time and effort needed to build the project. Based on
this information, you can evaluate technical and economic feasibility.
When you have identified the project, work with stakeholders to define
requirements. You can use the user flow diagram or the high-level UML diagram to
show the work of new features and show how it will apply to your existing system.
Construction/Iteration:
When the team defines the requirements, the work begins. Designers and
developers start working on their project, which aims to deploy a working product.
The product will undergo various stages of improvement, so it includes simple,
minimal functionality.
Testing:
In this phase, the Quality Assurance team examines the product's performance and
looks for bugs.
Deployment:
In this phase, the team issues a product for the user's work environment.
Feedback:
After releasing the product, the last step is feedback. In this, the team receives
feedback about the product and works through the feedback.