REVIEWER

1. Software product; software industry and the role of software engineering

 Impact of the software industry on society

o Driving force(make things happen) in business decision making
o Basis for modern scientific investigation & engineering problem solving
o Embedded(combination) in a variety of consumer products
o Internet & “dot com” companies
o Embedded Systems used in transportation, medicine, telecommunications,
entertainment, military, industrial , education
o Lone programmer to software team
 Software product; characteristics of software and impact on difficulties encountered in software
development
o Characteristics
 Abstract & intangible
 Developed/engineered
 Does not “wear out”
 Custom-built
o Impact on difficulties encountered in software development
 Software failure receive a lot more publicity than success stories
 Hardware advances continue to outpace ability (develop faster)
 New technologies, complex GUI place new demands on developers
 Unreliable, delivered late & over budget(chaos report)
 High reliability & quality
 Difficulty in maintaining
 No Silver Bullet by F.P.
o Two kinds of encountered difficulties(essential difficulties & accidental difficulties)
 Essential-difficulty inherit in nature of software, always remain
 Accidental-we make things harder for ourselves, can be remove
o Essential difficulties sources of difficulty(characteristics)
 Complexity
 When software entity scaled up, number of elements scale up as well,
these elements interact with each other. With this, describing and
testing the different elements is hard. Making it an essential one
because you can’t just ‘abstract(drawn) it away’
 Conformity
 Physics encounters complex objects- but with firm faith, connected
principles are found. There must be simplified explanations. For
software engineers, there is no faith comforts. The software’s problem
can be fixed by individual solutions.
 Changeability
 Software is bound to constantly change. It depends on the application
itself, the users, laws, and the compatibility of hardware. Thus forcedly
changing continually.
 Problems facing the software industry and how software engineering can help software
developers face such challenges
o Developers face heterogeneity challenge, delivery challenge, trust challenge
 Heterogeneity challenge-systems required to operate in different types of
computers & support systems.
 Delivery challenge-many traditional software engineering techniques are time-
consuming. In getting the quality of software.
 Trust challenge-software is connected to all aspects in our lives, so it is
necessary that we can trust the software.
o How software engineering can help software developers face this challenges
 HETEROGENEITY CHALLENGE: developing techniques for building dependable
software that is flexible
 DELIVERY CHALLENGE: shortening delivery times for large & complex systems
w/o negotiating quality
 TRUST CHALLENGE: develop techniques that demonstrates that the software
can be trusted
 Real life situations where software has caused great harm in a specific aspect of our existence
o Love Virus
 Loveletter infected millions of computer
 Cause: thru e-mail, internet chat and shared file systems
 Solution: don’t open unknown messages from unknown senders
 Computer-based systems and system engineering; relationship between system engineering and
software engineering
o Computer-based systems: consists of hardware, software, data, processes, policies,
people and documentation
o System engineering: concerned with all aspects of software production, high quality of
software is produced
o Relationship between system engineering and software engineering: They uses a life
cycle. They have requirements analysis, design, integration, testing and deployment.
 Software engineering; concepts, benefits, issues, best practices
o Concepts
 SDLC
 Requirements analysis
 Design
 Implementation and Unit Testing
 Integration
 System Testing
 Deployment and Maintenance
o Benefits
 ***research more
o Issues
 Cost-manpower, hardware, software and other resources
 Consistency
 Quality
 Schedule
 o Best practices
 Testing is essential
 Repositories let us fix our mistakes
 Development methodologies matter
 Code must live on
 Code analysis
2. Software Process and the different process models

 Software process concepts, the common process framework and the 4 fundamental process
activities
o Common Process Framework (CPF) – framework that is applicable to all software
projects
o 4 Fundamental process activities
 Specification – functionality of the software and constraints on its operation
must be defined
 Development – software meets specification(contains design and
implementation)
 Validation – ensure that all functionalities meet the customer needs
 Evolution – evolve to meet customer needs
 Process characteristics
o Understandability – how easy is it to understand the process definition
o Visibility – process activities conclude clear results
o Supportability – what extent can CASE tools be used to support process activities
o Acceptability – is process acceptable and usable by engineers to produce software
product
o Reliability – design in a way that process errors are avoided/trapped
o Robustness – continue in spite of unexpected problem
o Maintainability – Process evolve to reflect changing org. requirements
o Rapidly – How fast can the process of delivery a system be completed
 Process model; traditional versus agile models
Traditional Agile
Top down approach, making changes is Conducts experiments on various
not easy techniques
Leadership style Free flow of communication
Pre-planning is done Flexible
Customer is involved in initial phase Customer involvement is crucial
Project manager has ownership Shared ownership, every member is
equally responsible
One-time delivery Incremental delivery

 Characteristics of a process model and associated methods and tools

o Generic Models
 Waterfall model
 Characteristic: process phases are distinct and separate
 Methods : Linear Sequential
 o Requirements definition, system and software design,
implementation and unit testing, integration and system
testing, operation and maintenance
 Tool: Gantt chart, task lists
 Evolutionary Development
 Characteristic: Process phases are interleaved(mixed)
 Methods:
o Project planning, product specification, architectural design,
detailed design, coding debugging and documentation, testing
and analysis, maintenance
 Tools: deliverables, prototype
 Formal Systems development
 Characteristic: Mathematical system model is formally transformed to
an implementation
 Methods:
o Requirements definition, formal specification, formal
transformation, integration and system testing
 Tools: set theory, function theory and logic
 Reuse-based development
 Characteristic: system is assembled from existing components
 Methods:
o Requirements Specification, Component Analysis, Requirements
Modification, System Design with Reuse, Development and
Integration, System Validation
 Tools: same existing code is utilized with few necessary modifications
o Traditional Models
 Incremental Model
 Characteristics: broken down into mini development projects, partial
systems
 Methods:
o Requirement Analysis, Design Phase, Coding Phase, Testing
Phase, Maintenance Phase
 Tools: CASE Tools
 Spiral Model
 Characteristic: emphasizes risk analysis
 Methods:
o Objective setting, risk assessment and reduction, validation and
development, planning
 Tools: Software requirement engineering methodology(SREM)
 Package-Based Development Model
 Characteristic: use of commercial-off-the-shelf package (COTS)
 Methods:
o System requirement, collection of packages, developing
interfaces, developing refinements
 Tools: Autobundle-merge source packages
 Rational Unified Process
  Characteristic: UML, iterative model created by Rational Software
Corporation
 Methods:
o Inception Phase, Elaboration Phase, Construction Phase,
Transition Phase
 Tools: UML
 Component-Based
 Characteristic: independent components, component standards,
middleware, development process, integration of
 Methods:
o
 Tools: CORBA, JavaBeans, COM+
 Cleanroom Model
 Characteristic: “cleanroom environment”
 Methods:
o Requirements analysis, high-level design, detailed design
 Tools: coverage tools
o Agile Models
 Extreme Programming
 Characteristic: programming comes first
 Methods:
 Tools:
 Adaptive Software Development
 Characteristic: grew out of RAD
 Methods
 Tools:
 Feature Driven Development
 Characteristic: Functions
 Methods
 Tools
 Dynamic Systems Development Model
 Characteristic
 Methods
 Tools
 Scrum
 Wrapper Model
 Methods
 Tools
 Types of projects that are suitable for a particular model
o Generic
 Waterfall
 Requirements are stable & well understood
 Project with relatively short duration
 Evolutionary
 Small interactive systems
 Part of large systems
  Short-lifetime systems
 Formal Development
 Critical systems
 Safety/security case must be made
 Reuse Oriented Development
o Traditional
 Incremental Model
 Project is experimental or new
 Spiral Development Model
 Systems with strict requirements in terms of reliability and risk
management
 Package-Based Development Model
 Substantial portion of the desired functionality of a system can be
obtained through mature COTS packages
 Rational Unified Process

 Component-based Software Engineering
 CORBA, JavaBeans
 Cleanroom Model

o Agile
 Extreme Programming
 Embrace change
 Adaptive Software Development
 Embodies the principle that continuous learning and adaption of the
process to the work at hand is the normal state
 Feature Driven Development
 Developing by feature
 Dynamic Systems Development Method
 Project Life Cycle
 Scrum
 Time box is usually one month
3. Requirements Analysis
 Requirements: concept, types, characteristics
o User requirements – description of what services that system is expected to provide
and the constraints under which it must operate
o System requirements – detailed information about the system functions, services, and
operation constraints that are to be implemented
o Functional requirements – services that a system should provide and how the system
should react to particular input and how the system should behave in particular
situations
o Non-functional requirements – constraints on the services or functions offered by the
system
o Characteristics
 Unambiguous(clear)
 Complete
  Consistent
 Traceable
 Realistic
 Verifiable
 Valid
 Requirements engineering activities
o Feasibility study – determines whether the solution to accomplish the requirements is
practical and workable
o Requirements elicitation – discovering requirements of a system from users
o Requirements Analysis – determining the needs to meet for new product, taking
account of possibly conflicting requirements
o Requirements specification – description of a software system to be developed
o Requirements validation – ensuring the specified requirements meet the customer
needs
 Requirements elicitation and analysis: activities and techniques
o Activities
 Discovery – interacting and gathering the requirements from the stakeholders
 Classification and organization – putting related requirements together
 Prioritization and negotiation – prioritizing requirements and finding and
resolving requirements conflicts thru negotiations
 Documentation –functional and non-functional requirements are documented
o Techniques
 Interviews – discuss with different types of stake holders to understand
requirements
 Research -
 Questionnaires
 Observation
 Forms analysis
 Prototyping – representations or visualizations of actual system
 Difficulties encountered in requirements analysis and how such difficulties are handled
o Problems
 Stakeholders don’t know what they want - interview, prototype
 Stakeholders express requirements in their own terms - scenarios
 Different stakeholders may have conflicting requirements – prioritize and
negotiation until stake holder can compromise
 Organizational and political factors may influence the system requirements
 The requirements change during the analysis process
 Characteristics of a good analyst
o Able to communicate in writing and orally
o Easily get along with people
o Good listener
o Knowledgeable of technology
o Knowledgeable of business
 Requirements management
o Process of identifying, understanding, tracking and controlling changes to system
requirements
4. Software Design and Implementation
 Software design; concepts, principles, issues, techniques
o Design
 First step in the development phase
 Applying various techniques for defining a process in sufficient detail
o Software Design
 Design should be structured to accommodate change
o Principles
 Not suffer from tunnel vision
 Traceable to analysis
 Minimize intellectual distance
 Exhibit uniformity and integration
 Not coding
 Structured to accommodate change
 Technical reviews or design walkthroughs
 Readable
o Issues
 Concurrency
 Main concurrent activities
 Workflow and event handling
 How are events handled
 Distribution
 How is the system distributed
 Error handling and recovery
 What is the system behavior when failure occurs
 Persistence of data
 How complex is the data
 Characteristics of a good designer
o Correctness – implement all functionalities
o Understandability – easily understandable
o Efficiency – good use of time and energy
o Maintainability – easily amenable to change
 The design process
o Architectural Design
o Interface Design
o Component Design
o Data Design
o Algorithm Design
 Architectural Design
o Basic structural framework that identifies major components of system and
communication among these components
o Objectives
 Stakeholder communication
 Analysis
 Understanding of the solution
 Aids in complexity management
 Large-scale reuse
  Interface Design
o How the software communicates within self, systems that interact with it and humans
who use it
o Internal interface: between modules
o External interface: between software and other non-human procedures
o Human-computer/user interface
 Component Design
o Provides a way to determine whether the defined algorithms, data structures, and
interfaces will work properly
 Implementation concerns, issues, and guidelines
o Concerns
 Complexity: details are addressed and “work around” problems in order to cope
with complexity
 Change: code should be resilient(able to recover) to anticipate change
 Validation and verification: code structure should facilitate the v & v process
 Standards compliance – comply with the standards
 Platform sensitivity
o Issues and guidelines
 Length of code: short does not mean better, 30 second rule
 Readability and sensible organization
 Efficiency: optimized code
 Formatting: indent, align; case conventions; white space; proper splitting of long
statements across lines
 Naming convention: variables, classes, class
 Documentation: what and why of code; block vs in line comments
 Variables: declare immediately before use
 Clean resources
 Safe and defensive programming
 Coding standards: industry, project, personal
5. Verification & Validation
 Verification vs validation, dynamic vs static v&v
o Verification – set of activities that ensures that software correctly implements a specific
function and conforms to specification
o Validation – set of activities that ensure that the software meets customer
requirements
o Dynamic v&v technique-software testing; execution of implemented software w/ test
data
o Static v&v technique-software inspection; applicable at all stages in the process
 Testing concept; issues and principles, steps in testing, testability characteristics of software
o Principles
 Tests should be traceable to customer requirements
 Testing should begin in small progress towards testing large shit
 Testing is most effective when conducted by an independent third party
 Pareto principle(80/20) applies to software testing
 Design software for testability
 Review the test strategy
o Steps
 Design test cases
 Prepare test data
 Run program with test data
 Compare test result with test case
 Prepare test/bug report
 Debug
o Testability Characteristics
 Operability: better the target software works, the more efficiently it can be
tested
 Observability: what you see is what you test
 Controllability: the more software can be controlled the more testing can be
optimized and automated
 Decomposability: isolation of problems and retesting are easier by controlling
the testing scope
 Simplicity: the less there is to test, the quicker the test
 Stability: fewer changes mean fewer disruptions to testing, changes must be
controlled
 Understandability: the more information testers have, the better the tests
o Types
 Defect Testing
 Intent of finding errors
 Validation Testing
 Intended to demonstrate to the developer and customer that the
software meets its requirements
 Regression Testing
 Re-execution of some subset of tests to ensure that changes have not
propagated unintended side effects
o Approaches
 Black-box
 Check that input is properly accepted, output properly produced
 White-box
 Logical paths of a program
 Gray-box
 Tests inputs and outputs but design is educated by information about
the code
 Important with web applications
o Test Strategy
 Unit Test
 Verification effort on individual components
 System Test
 Involve testing an increment to be delivered to the customer
o Techniques
 Integration test
 Constructing program structure while conducting tests associated with
interfacing
 Release Test
  Tests the complete system(to be delivered)
 Software inspections/reviews; concepts, activities, benefits, guidelines
o Technical reviews: structured
o Benefits
 Uncover functional errors
 Verify conformance to requirements
 Enhance manageability of projects
 Backup and continuity
o Guidelines
 Review the product
 Set an agenda
 Discuss the problem
 Take notes
 Limit no. of participants
 Preparation should not take more than 2 hours
 Develop a checklist
 Allocate resources
 Conduct meaningful training
 Conduct follow-up
 Review previous reviews
6. Release and Version Management

7. Project Management and Scheduling

