Sunday, November 28, 2010
Monday, November 22, 2010
Software Process
Chapter 2 -Process Models
adapted from the book of Dr. Roger S. Pressman
Overview
· The roadmap to building high quality software products is software process.
· Software processes are adapted to meet the needs of software engineers and managers as they undertake the development of a software product.
· A software process provides a framework for managing activities that can very easily get out of control.
· Modern software processes must be agile, demanding only those activities, controls, and work products appropriate for team or product.
· Different types of projects require different software processes.
· The software engineer's work products (programs, documentation, data) are produced as consequences 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.
Software Process
· Framework for the activities, actions, and tasks required to build high quality software
· Defines approach taken as software is engineered
· Adapted by creative, knowledgeable software engineers so that it is appropriate for the products they build and the demands of the marketplace
Generic Process Framework
· Communication
· Planning
· Modeling
· Construction
· Deployment
Umbrella Activities (applied throughout process)
· Software project tracking and control
· Risk management
· Software quality assurance
· Formal technical reviews
· Measurement
· Software configuration management
· Reusability management
· Work product preparation and production
Process Flow
· Describes how each of the five framework activities, actions, and tasks are organized with respect to sequence and time
· Linear process flow executes each of the framework activities in order beginning with communication and ending with deployment
· Iterative process flow executes the activities in a circular manner creating a more complete version of the software with each circuit or iteration
· Parallel process flow executes one on more activities in parallel with other activities
Task Sets
· Each software engineering action associated with a framework activity can be represented by different task sets
· Small one person projects do not require task sets that are as large and detailed as complex projects team oriented project task sets
· Task sets are adapted to meet the specific needs of a software project and the project team characteristics
Process Patterns
· Templates or methods for describing project solutions within the context of software processes
· Software teams can combine patterns to construct processes that best meet the needs of specific projects
Process Pattern Template
· Meaningful pattern name
· Forces (environment in which the pattern is encountered and indicators that make problems visible and affect their solution)
· Type
o Stage patterns (define problems with a framework activity for the process)
o Task patterns (define problems associated with engineering action or work task relevant to successful software engineering practice)
o Phase patterns (define the sequence or flow of framework activities that occur within a process)
· Initial context (describes conditions that must be present prior to using pattern)
o What organizational or team activities have taken place?
o What is the entry state for the process?
o What software engineering or project information already exists?
· Solution (describes how to implement pattern correctly)
· Resulting context (describes conditions that result when pattern has been implemented successfully)
o What organization or team activities must have occurred?
o What is the exit state for the process?
o What software engineering information of project information has been developed?
· Related patterns (links to patterns directly related to this one)
· Known uses/examples (instances in which pattern is applicable)
Process Assessment and Improvement
· Standard CMMI Assessment Method for Process Improvement (SCAMPI) provides a five step process assessment model that incorporates five phases (initiating, diagnosing, establishing, acting, learning)
· CMM-Based Appraisal for Internal Process Improvement (CBAIPI) provides diagnostic technique for assessing the relative maturity of a software organization
· SPICE (ISO/IE15504) standard defines a set of requirements for process assessment
· ISO 9001:2000 for Software defines requirements for a quality management system that will produce higher quality products and improve customer satisfaction
Prescriptive Process Models
· Originally proposed to bring order to the chaos of software development
· They brought to software engineering work and provide reasonable guidance to software teams
· They have not provided a definitive answer to the problems of software development in an ever changing computing environment
Software Process Models
· Waterfall Model (classic life cycle - old fashioned but reasonable approach when requirements are well understood)
· Incremental Models (deliver software in small but usable pieces, each piece builds on pieces already delivered)
· Evolutionary Models
- Prototyping Model (good first step when customer has a legitimate need, but is clueless about the details, developer needs to resist pressure to extend a rough prototype into a production product)
- Spiral Model (couples iterative nature of prototyping with the controlled and systematic aspects of the Waterfall Model)
· Concurrent Development Model (concurrent engineering - allows software teams to represent the iterative and concurrent element of any process model)
Specialized Process Models
- Component-Based Development (spiral model variation in which applications are built from prepackaged software components called classes)
- Formal Methods Model (rigorous mathematical notation used to specify, design, and verify computer-based systems)
- Aspect-Oriented Software Development (aspect-oriented programming - provides a process for defining, specifying, designing, and constructing software aspects like user interfaces, security, and memory management that impact many parts of the system being developed)
Unified Process
· Use-case driven, architecture centric, iterative, and incremental software process
· Attempts to draw on best features of traditional software process models and implements many features of agile software development
· Phases
o Inception phase (customer communication and planning)
o Elaboration phase (communication and modeling)
o Construction phase
o Transition phase (customer delivery and feedback)
o Production phase (software monitoring and support)
Personal Software Process (PSP)
· Emphasizes personal measurement of both work products and the quality of the work products
· Stresses importance of indentifying errors early and to understand the types of errors likely to be made
· Framework activities
o Planning (size and resource estimates based on requirements)
o High-level design (external specifications developed for components and component level design is created)
o High-level design review (formal verification methods used to uncover design errors, metrics maintained for important tasks)
o Development (component level design refined, code is generated, reviewed, compiled, and tested, metric maintained for important tasks and work results)
o Postmortem (effectiveness of processes is determined using measures and metrics collected, results of analysis should provide guidance for modifying the process to improve its effectiveness)
Team Software Process
· Objectives
o Build self-directed teams that plan and track their work, establish goals, and own their processes and plans
o Show managers how to coach and motivate their teams and maintain peak performance
o Accelerate software process improvement by making CCM Level 5 behavior normal and expected
o Provide improvement guidance to high-maturity organizations
o Facilitate university teaching of industrial team skills
· Scripts for Project Activities
o Project launch
o High Level Design
o Implementation
o Integration and system testing
o Postmortem
Process Technology Tools
· Used to adapt process models to be used by software project team
· Allow organizations to build automated models of common process framework, task sets, and umbrella activities
· These automated models can be used to determine workflow and examine alternative process structures
· Tools can be used to allocate, monitor, and even control all software engineering tasks defined as part of the process model
Software Engineering
Software and Software Engineering
adapted from the book of Dr. Roger S. Pressman
Overview
· Software is designed and built by software engineers.
· Software is used by virtually everyone in society.
· Software is pervasive in our commerce, our culture, and our everyday lives.
· Software engineers have a moral obligation to build reliable software that does no harm to other people.
· Software engineers view computer software, as being made up of the programs, documents, and data required to design and build the system.
· Software users are only concerned with whether or not software products meet their expectations and make their tasks easier to complete.
Important Questions for Software Engineers
· Why does it take so long to get software 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 spend so much time and effort maintaining existing programs?
· Why do we continue to have difficulty in measuring progress as software is being developed?
Software
· Software is both a product and a vehicle for delivering a product (information).
· Software is engineered not manufactured.
· Software does not wear out, but it does deteriorate.
· Industry is moving toward component-based software construction, but most software is still custom-built.
Software Application Domains
· System software
· Application software
· Engineering or Scientific Software
· Embedded software
· Product-line software (includes entertainment software)
· Web-Applications
· Artificial intelligence software
New Software Challenges
· Open-world computing
o Creating software to allow machines of all sizes to communicate with each other across vast networks
· Netsourcing
o Architecting simple and sophisticated applications that benefit targeted end-user markets worldwide
· Open Source
o Distributing source code for computing applications so customers can make local modifications easily and reliably
Reasons for Legacy System Evolution
· Software must be adapted to meet needs of new computing environments or technology
· Software must be enhanced to implement new business requirements
· Software must be extended to make it interoperable with more modern system components
· Software must be re-architected to make it viable within a network environment
Unique Nature of Web Apps
· Network intensive
· Concurrency
· Unpredictable load
· Availability (24/7/365)
· Data driven
· Content sensitive
· Continuous evolution
· Immediacy (short time to market)
· Security
· Aesthetics
Software Engineering Realities
· Problem should be understood before software solution is developed
· Design is a pivotal activity
· Software should exhibit high quality
· Software should be maintainable
Software Engineering
· Software engineering is the establishment of sound engineering principles in order to obtain reliable and efficient software in an economical manner.
· Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software.
· Software engineering encompasses a process, management techniques, technical methods, and the use of tools.
Generic Software Process Framework
· Communication (customer collaboration and requirement gathering)
· Planning (establishes engineering work plan, describes technical risks, lists resources required, work products produced, and defines work schedule)
· Modeling (creation of models to help developers and customers understand the requires and software design)
· Construction (code generation and testing)
· Deployment (software delivered for customer evaluation and feedback)
Software Engineering Umbrella Activities
· Software project tracking and control (allows team to assess progress and take corrective action to maintain schedule)
· Risk management (assess risks that may affect project outcomes or quality)
· Software quality assurance (activities required to maintain software quality)
· Technical reviews (assess engineering work products to uncover and remove errors before they propagate to next activity)
· Measurement (define and collect process, project, and product measures to assist team in delivering software meeting customer needs)
· Software configuration management (manage effects of change)
· Reusability management (defines criteria for work product reuse and establish mechanisms to achieve component reuse)
· Work product preparation and production (activities to create models, documents, logs, forms, lists, etc.)
Attributes for Comparing Process Models
· Overall flow and level of interdependencies among tasks
· Degree to which work tasks are defined within each framework activity
· Degree to which work products are identified and required
· Manner in which quality assurance activities are applied
· Manner in which project tracking and control activities are applied
· Overall degree of detail and rigor of process description
· Degree to which stakeholders are involved in the project
· Level of autonomy given to project team
· Degree to which team organization and roles are prescribed
Essence of Practice
· Understand the problem (communication and analysis)
· Plan a solution (software design)
· Carry out the plan (code generation)
· Examine the result for accuracy (testing and quality assurance)
Understand the Problem
· Who are the stakeholders?
· What functions and features are required to solve the problem?
· Is it possible to create smaller problems that are easier to understand?
· Can a graphic analysis model be created?
Plan the Solution
· Have you seen similar problems before?
· Has a similar problem been solved?
· Can readily solvable subproblems be defined?
· Can a design model be created?
Carry Out the Plan
· Does solution conform to the plan?
· Is each solution component provably correct?
Examine the Result
· Is it possible to test each component part of the solution?
· Does the solution produce results that conform to the data, functions, and features required?
Software Practice Core Principles
1. Software exists to provide value to its users
2. Keep it simple stupid (KISS)
3. Clear vision is essential to the success of any software project
4. Always specify, design, and implement knowing that someone else will have to understand what you have done to carry out his or her tasks
5. Be open to future changes, don’t code yourself into a corner
6. Planning ahead for reuse reduces the cost and increases the value of both the reusable components and the systems that require them
7. Placing clear complete thought before any action almost always produces better results
Software Creation
· Almost every software project is precipitated by a business need (e.g. correct a system defect, adapt system to changing environment, extend existing system, create new system)
· Many times an engineering effort will only succeed if the software created for the project succeeds
· The market will only accept a product is the software embedded within it meets the customer’s stated or unstated needs
Subscribe to:
Posts (Atom)