UNIT II-PLANNING AND MANAGING THE PROJECT
Planning and Managing the Project
Tracking Progress
• Do we understand customer’s needs?
• Can we design a system to solve customer’s problems or satisfy customer’s needs?
• How long will it take to develop the system?
• How much will it cost to develop the system?
Project Schedule
• Describes the software-development cycle for a particular project by
– enumerating the phases or stages of the project
– breaking each phase into discrete tasks or activities to be completed
• Portrays the interactions among the activities and estimates the times that each task or activity will take
Project Schedule: Approach
• Understanding customer’s needs by listing all project deliverables
– Documents
– Demonstrations of function
– Demonstrations of subsystems
– Demonstrations of accuracy
– Demonstrations of reliability, performance or security
• Determining milestones and activities to produce the deliverables
Milestones and activities
• Activity: takes place over a period of time
• Milestone: completion of an activity -- a particular point in time
• Precursor: event or set of events that must occur in order for an activity to start
• Duration: length of time needed to complete an activity
• Due date: date by which an activity must be completed
Project Personnel
• Key activities requiring personnel
– requirements analysis
– system design
– program design
– program implementation
– testing
– training
– maintenance
– quality assurance
• There is great advantage in assigning different responsibilities to different people
Choosing Personnel
• Ability to perform work
• Interest in work
• Experience with
– similar applications
– similar tools, languages, or techniques
– similar development environments
• Training
• Ability to communicate with others
• Ability to share responsibility
Management skills
• A project's progress is affected by
– degree of communication
– ability of individuals to communicate their ideas
• Software failures can result from breakdown in communication and understanding
Project Organization
• Depends on
– backgrounds and work styles of team members
– number of people on team
– management styles of customers and developers
• Examples:
– Chief programmer team: one person totally responsible for a system's design and development
– Egoless approach: hold everyone equally responsible
Effort Estimation
• Estimating project costs is one of the crucial aspects of project planning and management
• Estimating cost has to be done as early as possible during the project life cycle
• Type of costs
– facilities: hardware, space, furniture, telephone, etc
– software tools for designing software
– staff (effort): the biggest component of cost
Type of Estimation Methods
• Expert judgment
• Top-down or bottom-up
• Analogy: pessimistic (x), optimistic (y), most likely (z); estimate as (x + 4y + z)/6
• Delphi technique: based on the average of “secret” expert judgments
• Algorithmic methods: E = (a + bSc) m(X)
• Walston and Felix model: E = 5.25 S 0.91
• Bailey and Basili model: E = 5.5 + 0.73 S1.16
COCOMO model
• Introduced by Boehm
• COCOMO II
– updated version
– include models of reuse
• The basic models
– E = bScm(X)
– where
• bSc is the initial size-based estimate
• m(X) is the vector of cost driver information
Risk Management
• Risk is an unwanted event that has negative consequences
• Distinguish risks from other project events
– Risk impact: the loss associated with the event
– Risk probability: the likelihood that the event will occur
• Quantify the effect of risks
– Risk exposure = (risk probability) x (risk impact)
• Risk sources: generic and project-specific
• Three strategies for risk reduction
• Avoiding the risk: change requirements for performance or functionality
• Transferring the risk: transfer to other system, or buy insurance
• Assuming the risk: accept and control it
• Cost of reducing risk
• Risk leverage = (risk exposure before reduction – (risk exposure after reduction) / (cost of risk reduction)
Boehm’s Top Ten Risk Items
• Personnel shortfalls
• Unrealistic schedules and budgets
• Developing the wrong functions
• Developing the wrong user interfaces
• Gold-plating
• Continuing stream of requirements changes
• Shortfalls in externally-performed tasks
• Shortfalls in externally-furnished components
• Real-time performance shortfalls
• Straining computer science capabilities
Project Plan
Project Plan Contents
• Project scope
• Project schedule
• Project team organization
• Technical description of system
• Project standards and procedures
• Quality assurance plan
• Configuration management plan
• Documentation plan
• Data management plan
• Resource management plan
• Test plan
• Training plan
• Security plan
• Risk management plan
• Maintenance plan
Project Plan Lists
• List of the people in development team
• List of hardware and software
• Standards and methods, such as
– algorithms
– tools
– review or inspection techniques
– design language or representaions
– coding languages testing techniques
Process Models and Project Management
• Establish an appropriately large shared vision
• Delegate completely and elicit specific commitments from participants
• Inspect vigorously and provide supportive feedback
• Acknowledge every advance and learn as the program progresses
Information System Example
Piccadilly System
• Using COCOMO II
• Three screens and one report
– Booking screen: complexity simple, weight 1
– Ratecard screen: complexity simple, weigth 1
– Availability screen: complexity medium, weight 2
– Sales report: complexity medium, weight 5
• Estimated effort = 182 person-month
Ariane-5 System
• The Ariane-5 destruction might have been prevented had the project managers developed a risk management plan
– Risk identification: possible problem with reuse of the Ariane-4)
– Risk exposure: prioritization would have identified if the inertial reference system (SRI) did not work as planned
– Risk control: assesment of the risk using reuse software
– Risk avoidance: using SRI with two different designs
The Requirements Process
• A requirement is an expression of desired behavior
• A requirement deals with
– objects or entities
– the state they can be in
– functions that are performed to change states or object characteristics
• Requirements focus on the customer needs, not on the solution or implementation
– designate what behavior, without saying how that behavior will be realized
Why Are Requirements Important
• Top factors that caused project to fail
– Incomplete requirements
– Lack of user involvement
– Unrealistic expectations
– Lack of executive support
– Changing requirements and specifications
– Lack of planning
– System no longer needed
• Some part of the requirements process is involved in almost all of these causes
• Requirements error can be expensive if not detected early
• Performed by the req. analyst or system analyst
• The final outcome is a Software Requirements Specification (SRS) document
Agile Requirements Modeling
• If requirements are tighly coupled and complex, we may be better off with a “heavy” process that empasizes up-front modeling
• If the requirements are uncertain, agile methods are an alternative approach
• Agile methods gather and implement the requirements in increments
• Extreme Programming (XP) is an agile process
– The requirements are defined as we build the system
– No planning or designing for possible future requirements
– Encodes the requirements as test cases that eventually implementation must pass
Requirements Elicitation
• Customers do not always undertand what their needs and problems are
• It is important to discuss the requirements with everyone who has a stake in the system
• Come up with agreement on what the requirements are
– If we can not agree on what the requirements are, then the project is doomed to fail
Requirements Elicitation Stakeholders
• Clients: pay for the software to be developed
• Customers: buy the software after it is developed
• Users: use the system
• Domain experts: familiar with the problem that the software must automate
• Market Researchers: conduct surveys to determine future trends and potential customers
• Lawyers or auditors: familiar with government, safety, or legal requirements
• Software engineers or other technology experts
Using Viewpoints to Manage Inconsistency
• No need to resolve inconsitencies early in the requirements process (Easterbrook and Nuseibah, 1996)
• Stakeholders' views documented and maintained as separate Viewpoints through the software development process
– The requirements analyst defines consistency rules that should apply between Viewpoints
– The Viewpoints are analyzed to see if they conform to the consistency requirements
• Inconsistencies are highlighted but not adressed until there is sufficient information to make informed decision
• Interviewing stake holders
• Reviewing available documentations
• Observing the current system (if one exists)
• Apprenticing with users to learn about user's task in more details
• Interviewing user or stakeholders in groups
• Using domain specific strategies, such as Joint Application Design, or PIECES
• Brainstorming with current and potential users
Types of Requirements
• Functional requirement: describes required behavior in terms of required activities
• Quality requirement or nonfunctional requirement: describes some quality characteristic that the software must posses
• Design constraint: a design decision such as choice of platform or interface components
• Process constraint: a restriction on the techniques or resources that can be used to build the system
Making Requirements Testable
• Fit criteria form objective standards for judging whether a proposed solution satisfies the requirements
– It is easy to set fit criteria for quantifyable requirements
– It is hard for subjective quality requirements
• Three ways to help make requirements testable
– Specify a quantitave description for each adverb and adjective
– Replace pronouns with specific names of entities
– Make sure that every noun is defined in exaclty one place in the requirements documents
Types of Requirements Resolving Conflicts
• Different stakeholder has different set of requirements
– potential conflicting ideas
• Need to prioritize requirements
• Prioritization might separate requirements into three categories
– essential: absolutely must be met
– desirable: highly desirable but not necessary
– optional: possible but could be eliminated
Two Kinds of Requirements Documents
• Requirements definition: a complete listing of everything the customer wants to achieve
– Describing the entities in the environment where the system will be installed
• Requirements specification: restates the requirements as a specification of how the proposed system shall behave
Characteristics of Requirements
• Correct
• Consistent
• Unambigious
• Complete
• Feasible
• Relevant
• Testable
• Traceable
Modeling Notations
• It is important to have standard notations for modeling, documenting, and communicating decisions
• Modeling helps us to understand requirements thoroughly
– Holes in the models reveal unknown or ambiguous behavior
– Multiple, conflicting outputs to the same input reveal inconsistencies in the requirements
Entity-Relationship Diagrams
• A popular graphical notational paradigm for representing conceptual models
• Has three core constructs
ER Diagrams Example: UML Class Diagram
• UML (Unified Modeling Language) is a collection of notations used to document software specifications and designs
• It represents a system in terms of
– objects: akin to entities, organized in classes that have an inheritance hierarchy
– methods: actions on the object's variables
• The class diagram is the flagship model in any UML specification
– A sophisticated ER diagram relating the classes (entities) in the specification
Event Traces
• A graphical description of a sequence of events that are exchanged between real-world entities
– Vertical line: the timeline of distinct entity, whose name appear at the top of the line
– Horizontal line: an event or interaction between the two entities bounding the line
– Time progresses from top to bottom
• Each graph depicts a single trace, representing one of several possible behaviors
• Traces have a semantic that is relatively precise, simple and easy to understand
Functions and Relations Example: Decision Tables
Algebraic Specifications Example: SDL Data
Requirements and Specification Languages Unified Modeling Language (UML)
Requirements and Specification Languages Specification and Description Language (SDL)
Requirements and Specification Languages SDL System Diagram
Requirements and Specification Languages SDL Block Diagram
Prototyping Requirements Building a Prototype
Prototyping Requirements Prototyping vs. Modeling
• Prototyping
– Good for answering questions about the user interfaces
• Modeling
– Quickly answer questions about constraints on the order in which events should occur, or about the synchronization of activities
Requirements Documentation Requirement Definition: Steps Documenting Process
Validation and Verification
• In requirements validation, we check that our requirements definition accurately reflects the customer's needs
• In verification, we check that one document or artifact conforms to another
• Verification ensures that we build the system right, whereas validation ensures that we build the right system
Measuring Requirements
Choosing a Specification Technique Criteria for Evaluating Specification Methods
Information System Example
Real-Time Example
UNIT III-DESIGNING THE SYSTEM
Designing the Architecture
The Design Process
• Design is the creative process of figuring out how to implement all of the customer’s requirements; the resulting plan is also called the design
• Early design decisions address the system’s architecture
• Later design decisions address how to implement the individual units
Design is a Creative Process
• Many ways to leverage existing solutions
Many tools for understanding options and evaluating chosen architecture, including
Design Process Model
Collaborative Design
Agile Architectures
• Helpful to use agile process when there is a great deal of uncertainly about requirements
• Agile architectures are based on four premises:
• Possible problems with agile methods:
Modeling Architectures
• Collection of models helps to answer whether the proposed architecture meets the specified requirements
• Six ways to use the architectural models:
Decomposition and Views
Popular Design Methods
• Some design problems have no existing solutions
– Designers must decompose to isolate key problems
• Some popular design methods:
– Functional decomposition
– Feature-oriented decomposition
– Data-oriented decomposition
– Process-oriented decomposition
– Event-oriented decomposition
– Object-oriented design
Popular Design Methods
• Functional decomposition
• Feature-oriented decomposition
• Data-oriented decomposition
Process-oriented decomposition
Decomposition and Views
• Component
• Subsystem
• Runtime process
• Module
• Class
• Package
• Library
• Procedure
• Software unit
• Modular
• Well-defined
• Component-based software engineering (CBSE) is a method of software development whereby systems are created by assembling together preexisting components
• A component is “a self-contained piece of software with a well-defined set of interfaces” that can be developed, bought, and sold as a distinct entity
• The goal of CBSE is to support the rapid development of new systems, by reducing development to component integration, and to ease the maintenance of such systems by reducing maintenance to component replacement
• At this point, CBSE is still more of a goal than a reality with considerable on-going research
Architectural Views
• Common types of architectural views include:
– Decomposition view
– Dependencies view
– Generalization view
– Execution view
– Implementation view
– Deployment view
– Work-assignment view
Dependencies View
• The dependencies view shows dependencies among software units
• This view is useful in project planning
• Also useful for assessing the impact of making a design change to some software unit
Generalization View
Execution View
Implementation View
Deployment View
Work-assignment View
Architectural Styles and Strategies
• Pipes-and-Filter
• Client-Server
• Peer-to-Peer
• Publish-Subscribe
• Repositories
• Layering
Achieving Quality Attributes
• Architectural styles provide general beneficial properties. To support specific quality attribute tactics are utilized:
– Modifiability
– Performance
– Security
– Reliability
– Robustness
– Usability
– Business goals
Collaborative Design
• Usually the design of software systems is performed by a team of developers
• Several issues must be addressed by the team:
– Who is best suited to design each aspect of the system
– How to document all aspects
– How to coordinate and integrate the software units
• Important to view group interaction in its cultural and ethical contexts
The Causes of Design Breakdown
Documenting Software Architectures
• Document rationale: outlining critical issues and trade-offs
When to document the rationale behind decision
Architecture Design Review
Software Product Lines
Designing the Modules
Design Methodology
Refactoring
• Design decisions are periodically revisited and revised
• Refactoring
• Objective: to simplify complicated solutions or to optimize the design
Design Principles
• Design principles are guidelines for decomposing a system’s required functionality and behavior into modules
• The principles identify the criteria
– for decomposing a system
– deciding what information to provide (and what to conceal) in the resulting modules
• Six dominant principles:
– Modularity
– Interfaces
– Information hiding
– Incremental development
– Abstraction ,Generality
Faking” a Rationale Design Process
OO Design
• A class is a software module that partially or totally implements an abstract data type
• If a class is missing implementations for some of its methods, we say that it is an abstract class
• The class definition includes constructor methods that spawn new object instances
• Instance variables are program variables whose values are references to objects
Inheritance vs. Object Composition
Substitutability
Law of Demeter
: Allows reducing dependencies by including in each composite class methods for operating on the class’s components
Dependency Inversion
Representing OO Designs in the UML
UML in the Process
• Use case diagrams
• UML activity diagrams
• Domain model
• Component diagrams
• Deployment diagrams
• Class diagrams
• Interaction diagrams
• Sequence diagrams
• Communication diagrams
• Activity diagrams
• State diagrams
• Package diagrams
OO Design Patterns
Other Design Considerations
OO Measurement
OO Size Measures
OO Design Quality Measures
Design Documentation
UNIT IV-TESTING THE PROGRAMS
Writing the Programs
Programming Standards and Procedures
• Standards for you
– methods of code documentation
• Standards for others
– Integrators, maintainers, testers
– Prologue documentation
– Automated tools to identify dependencies
• Matching design with implementation
– Low coupling, high cohesion, well-defined interfaces
Programming Standards at Microsoft
Programming Guidelines
Algorithms
Control Structures
Data Structures
Documentation
• Internal documentation
– header comment block
– meaningful variable names and statement labels
– other program comments
– format to enhance understanding
– document data (data dictionary)
• External documentation
– describe the problem
– describe the algorithm
– describe the data
Testing the Programs
Software Faults and Failures
• Wrong requirement: not what the customer wants
• Missing requirement
• Requirement impossible to implement
• Faulty design
• Faulty code
• Improperly implemented design
Objective of Testing
Types of Faults
Testing Issues
Testing Organization
Testing Object-Oriented Systems
Test Planning
• Establish test objectives
• Design test cases
• Write test cases
• Test test cases
• Execute tests
• Evaluate test results
Purpose of the Plan
• Test plan explains
– who does the testing
– why the tests are performed
– how tests are conducted
– when the tests are scheduled
Automated Testing Tools
• Dynamic analysis
– program monitors: watch and report program’s behavior
• Test execution
– Capture and replay
– Stubs and drivers
– Automated testing environments
• Test case generators
UNIT V-MAINTAINING THE SYSTEM
Testing the System
Principles of System Testing
Techniques Used in System Testing
Regression Testing
The Consequences of Not Doing Regression Testing
Configuration Management
Deltas and Separate Files
Test Team
Function Testing
Performance Tests
Purpose and Roles
Types of Performance Tests
• Stress tests
• Volume tests
• Configuration tests
• Compatibility tests
• Environmental tests
• Quality tests
• Recovery tests
• Maintenance tests
• Documentation tests
• Human factors (usability) tests
• Regression tests
• Security tests
• Timing tests
Reliability, Availability, and Maintainability Definition
Acceptance Tests
• Pilot test: install on experimental basis
• Alpha test: in-house test
• Beta test: customer pilot
• Parallel testing: new system operates in parallel with old system
Installation Testing
• Before the testing
– Configure the system
– Attach proper number and kind of devices
– Establish communication with other system
• The testing
– Regression tests: to verify that the system has been installed properly and works
Automated System Testing
Test Documentation
• Test plan: describes system and plan for exercising all functions and characteristics
• Test specification and evaluation: details each test and defines criteria for evaluating each feature
• Test description: test data and procedures for each test
• Test analysis report: results of each test
Testing Safety
Delivering the System
• It is more than just putting the system in place
• It is also helping users to understand and feel comfortable with the system
– Training
– Documentation
Training
Documentation
No comments:
Post a Comment