CIS 351 Chapters 1 - 7

creating a preliminary use case

(1) what to write about (2) how much to write about it (3) how detailed to make your description (4) how to organize the description example page 155

Common Agile process models

- Adaptive Software development ASD - Scrum - Dynamic systems development method DSDM - Crystal - Feature driven development FDD - Lean software development LDD - Agile Modeling AM - Agile unified process AUP

associations and dependencies

- two analysis classes are often related to one another in some fashion - in many instances, a client server relationship exists between two analysis classes

requirements elicitation or requirements gathering

combines elements of problem solving, elaboration, negotiation, and specification. in order to encourage a collaborative, team-oriented approach to requirements gathering, stakeholders work together to identify the problem, propose elements of the solution, negotiate different approaches and specify a preliminary set of solution requirements.

Linear process flow

executes each of the five framework activities in sequence, beginning with communication and culminating with deployment

responsibilities

five guidelines for allocating responsibilities to classes: 1. system intelligence should be distributed across classes to best address the needs of the problem 2. each responsibility should be stated as generally as possible 3. information and the behavior related to it should reside within the same class 4. information about one thing should be localized within a single class, not distributed across multiple classes 5. responsibilities should be shared among related classes, when appropriate

failure curve for hardware

high failure rate during infant mortality and wear out phase. Curve is a wide U.

developing an activity diagram

the UML activity diagram supplements the use case by providing a graphical representation of the flow of interaction within a specific scenario. similar to the flowchart, an activity diagram uses rounded rectangles to imply a specific system function, arrows to represent flow through the system, decision diamonds to depict a branching decision, and solid horizontal lines to indicate that parallel activities are occurring. example on page 162

requirements modeling approaches

(1) structured analysis (2) object-oriented analysis

formal methods model

- formal mathematical specification of computer software - not mainstream - a variation of this approach is called cleanroom software engineering Concerns: - time consuming - few developers have necessary background - difficult to use models as communication mechanism for technically unsophisticated customers

elements of the analysis model

- scenario based elements - class based elements - behavioral elements - flow oriented elements

elements of the requirements model

- scenario-based elements - class-based elements - behavioral elements - flow oriented elements

analysis rules of thumb

- the model should focus on requirements that are visible within the problem or business domain. the level of obstruction should be relatively high. - each element of the requirements model should add to an overall understanding of software requirements and provide insight into the information domain, function, and behavior of the system. - delay consideration of infrastructure and other non-functional models until design. that is, a database may be required, but the classes necessary to implement it, the functions required to access it, and the behavior that will be exhibited as it is used should be considered only after the problem domain analysis has been implemented. - minimize coupling throughout the system. it is important to represent relationships between classes and functions. however, if the level of interconnectedness is extremely high, effort should be made to reduce it - be certain that the requirements model provides value to all stakeholders. each constituency has its own use for the model. for example, business stakeholders should use the model to validate requirements; designers should use the model as a basis for design; QA people should use the model to help plan acceptance tests - keep the model as simple as it can be. don't create additional diagrams when they add no new information. don't use complex notational forms, when a sample list will do

questions that are asked when computer-based systems are built

- why does It take so long to get software finished? - why are development costs so high? - why do we spend so much time and effort maintain existing programs? - why do we continue to have difficulty in measuring progress as software is being developed and maintained?

Key traits for people on an agile team and the team itself

1. competence 2. common focus 3. collaboration 4. decision-making ability 5. fuzzy problem-solving ability 6. mutual trust and respect 7. self-organizer

Collaboration is not easy. People working together must trust one another to:

1. criticize without animosity 2. assist without resentment 3. work has hard as or harder than they do 4. have the skill set to contribute to the work at hand 5. communicate problems or concerns in a way that leads to an effective actions

DSDM Consortium defines an agile process model called DSDM life cycle which defines three different iterative cycles and two additional life cycle activities.

1. feasibility study 2. business study 3. functional model iteration 4. design and build iteration 5. implementation

agile software process address a number of key assumption about majority of software projects:

1. it is difficult to predict in advance which software requirements will persist and which will change. It is difficult to predict how customer priorities will change as the project proceeds. 2. For many types of software, design and construction are interleaved. That is, both activities should be performed in tandem so that design models are proven as they are created. It is difficult to predict how much design is necessary before construction is used to prove the design. 3. analysis, design, construction, and testing are not as predictable (from a planning point of view) as we might like Given these three assumptions, how do we create a process that can manage unpredictability? ... process adaptability. An agile process must be adaptable

Issues that trouble the critics of XP

1. requirements volatility 2. conflicting customer needs 3. requirements are expressed informally 4. lack of formal design

six selection characteristics that should be used as you conisder each potential class for inclusion in the analysis model

1. retained information 2. needed services 3. multiple attributes 4. common attributes 5. common operations 6. essential requirements page 170

software has characteristics that are considerably different that those of hardware

1. software is developed or engineered; it is not manufactured in the classical sense 2. software doesn't "wear out" 3. although the industry is moving toward component-base construction, most software continues to be custom built

Anchor point milestones

A combinations of work products and conditions that are attained along the path of the spiral - are noted for each evolutionary pass

Software Engineering Layers

A quality focus (base) process methods tools (top)

Spiral Model

An evolutionary process model that couples the iterative nature of prototyping with the controlled and systemic aspects of the waterfall model Provides the potential for rapid deployment of increasingly more complete versions of the software Originally proposed by Barry Boehm

people factors

As Cockburn and Highsmith state "agile development focuses on the talents and skills of individuals, molding the process to specific people and teams." the key point in this statement is that the process molds to the needs of the people and team, not the other way around.

requirements engineering: inception

At project inception, you should establish a basic understanding of the problem, the people who want a solution, the nature of the solution that is desired, and the effectiveness of preliminary communication and collaboration between the stakeholders and the software team. most projects begin when a business need is identified or a potential new market or service is discovered. Stakeholders from the business community define a business case for the idea, try to identify the breadth and depth of a market, do a rough feasibility analysis, and identify a working description of the project's scope.

class-responsibility-collaborator CRC modeling

CRC modeling provides a simple means for identifying and organizing the classes that are relevant to system or product requirements. CRC model may make use of actual or virtual index cards. the intent is to develop an organized representation of classes. responsibilities are the attributes and operates that are relevant for the class. stated simply, a responsibility is "anything the class knows or does". collaborators are those classes that are required to provide a class with the information needed to complete a responsibility. in general, a collaboration implies either a request for information or a request for some action.

XP Values

Communication Simplicity Feedback Courage By following each of these values, the agile team inculcates respect among its members, between stakeholders and team members, and indirectly, for the software itself. As they achieve successful delivery of the software increments, the team develops growing respect for the XP process.

Prescriptive Process Models

Define a prescribed set of process elements and a predictable process work flow. All software process models can accommodate the generic framework activities, but each applies a different emphasis to these activities and defines a process flow that invokes each framework activity in a different manner.

Personal Software Process (PSP)

Emphasizes personal measurement of both work products and quality of work products Stresses importance of identifying errors early and to understand the types of errors PSP defines five framework activities: Planning, High-level design, High-level design review, Development, Postmortem

Establishing The Groundwork for software requirements

In an ideal setting, stakeholders and software engineers work together on the same team. in such cases, requirements engineering is simply a matter of conducting meaningful conversation with colleagues. but reality is different. Steps: 1. identifying stakeholders 2. recognizing multiple viewpoints 3. working toward collaboration 4. asking the first questions

Phases of the Unified Process

Inception - communication and planning Elaboration - planning and modeling Construction - construction Transition - construction and deployment production - release software increment UP phases are similar in intent to the generic framework activities A software engineering workflow is distributed across all UP phases. In the context of UP, a workflow is analogous to a task set. page 55

incremental developmental strategy

Software increments must be delivered in short periods of time so that adaptation keeps pace with change.

Software Requirements Specification template

Table of Contents Revision History 1. introduction 2. overall decription 3. system features 4. external interface requirements 5. other nonfunctional requirements 6. other requirements appendix A: glossary appendix B: analysis models appendix C: issue list

scrum meeting questions:

What did you do in last team meeting? What obstacles are you encountering? What do you plan to accomplish by next team meeting?

process

a collection of activities, actions, and tasks that are performed when some work product is to be created

Quality Function Deployment (QFD)

a quality management technique that translates the needs of the customer into technical requirements for software. QFD "concentrates on maximizing customer satisfaction from the software engineering process". to accomplish this QFD emphasizes an understanding of what is valuable to the customer and then deploys these values throughout the engineering process. QFD identifies three types of requirements: (1) normal requirements (2) expected requirements (3) exciting requirements

Agile Coding

after stories are developed and preliminary design work is done, the team does not move to code, but rather develops a series of unit tests that will exercise each of the stories that is to be included in the current release. a key concept during the coding activity is pair programming

what characterizes an "agile" process?

agile process models emphasize project agility and follow a set of principles that lead to a more informational approach to software process. They are characterized as agile because they emphasize maneuverability and adaptability. Appropriate for many types of projects but especially when WebApps are engineered.

XP acceptance tests

also called customer tests are specified by the customer and focus on overall system features and functionality that are visible and reviewable by the customer. Acceptance tests are derived from the user stories that have been implemented as part of a software release.

Analysis Packages

an important part of analysis modeling is categorization. that is, various elements of the analysis model are categorized in a manner that packages them as a grouping called an analysis package, which is given a representative name.

legacy system

an old system that is fast approaching or beyond the end of its useful life within an organization; characterized by longevity and business criticality, but also by poor quality.

Analysis patterns

anyone who has done requirements engineering on more than a few software projects begins to notice that certain problems reoccur across all projects within a specific application domain. these analysis patterns suggest solutions (class, function, behavior) within the application domain that can be reused when modeling many applications. two benefits with the use of analysis patterns: (1) analysis patterns speed up the development of abstract analysis models that capture the main requirements of the concrete problem by providing the reusable analysis models with examples as well as a description of advantages and limitations. (2) analysis patterns facilitate the transformation of the analysis model into a diagram model by suggesting design patterns and reliable solutions for common problems.

validating requirements

as each element of the requirements model is created, it is examined for inconsistency, omissions, and ambiguity. the requirements represented by the model are prioritized by the stakeholders and grouped within requirements packages that will be implemented as software increments. a review of the requirements model addresses these questions: - is each requirement consistent with the overall objects for the system - have all requriements been specified at the proper level of abstraction - is the requriement really necessary - is each requirement bounded and unambiguous - etc page 144

usage scenarios

as requirements are gathered, an overall vision of system functions and features begins to materialize. however, it is difficult to move into more technical software engineering activities until you understand how these functions and features will be sued by different classes of end users. to accomplish this, developers and users can create a set of scenarios that identify a thread of usage for the system to be constructed. the scenarios, often called use cases, provide a descriptions of how the system will used.

Specifying Attributes

attributes describe a class that has been selected for inclusion in the requirements model. in essence, it is the attributes that define the class -- that clarify what is meant by the class in the context of the problem space. to develop a meaningful set of attributes for an analysis class, you should study each use case and select those things that reasonably belong to the class. in addition, the following question should be answered for each: what data items (composite or elementary) fully define this class in the context of the problem at hand?

Classes

basic guidelines for identifying classes and objects were presented earlier in this chapter. the taxonomy of class types presented can be extended by considering the following categories: - entity classes, also called model or business classes, are extracted directly from the statement of the problem. these classes typically represent things that are to be stored in a databased and persist throughout the duration of the application. - boundary classes manage a "unit of work" from start to finish. this is, controller classes can be design to manage (1) the creation or update of entity objects (2) the installation of boundary objects as they obtain information from entity objects (3) complex communication between sets of objects (4) validation of data communicated between objects or between the user and application. in general controller classes are not considered until after the design activity has begun

Unified Process

book by Iver Jacobson, Grady Booch, and James Rumbaugh attempt to draw on the best features and characteristics of traditional models but characterize them in a way that implements many of the best principles of agile models. Recognizes the importance of customer communication and streamlined methods for describing the customer's view of a system.

collaborations

classes fulfill their responsibilities in one of two ways (1) a class can use its own operations to manipulate its own attributes, thereby fulfilling a particular responsibility, or (2) a class can collaborate with other classes. collaborations are identified by determining whether a class can fulfill each responsibility itself. if it cannot, then it needs to interact with another class. to help in the identification of collaborators, you can examine three different generic relationships between classes (1) the is-part-of relationship (2) the has-knowledge-of relationship and (3) the depends-upon relationship.

relationships

data objects are connected to one another in different ways. consider the two data objects, person and car. a connection is established between person and car because the two objects are related. to determine "what are relationships" you should understand the role of people and case within the context of the software to be built. - a person owns a car - a person is insured to drive a car page 166

data attributes

define the properties of a data object and take on one of three different characteristics. they can be used to (1) name an instance of the data object (2) describe the instance (3) make reference to another instance in another table. In addition one or more of the attributes must be defined as an identifies. the identifier attribute becomes a "key" when we want to find an instance of the data object. in some cases, values for the identifiers are unique, although this is not a requirement. referring to the dat object car, a reasonable identifier might be the ID number.

refining a preliminary use care

each step in the preliminary use case is evaluated by asking the following questions: - can the actor take some other action at this point - is it possible that the actor will encounter some error condition at this point? if so, what might it be? - is it possible that the actor will encounter some other behavior at this point? if so, what might it be? the following issues should also be explored: - are there cases in which some "validation function" occurs during this use case? this implies that validation function is invoked and a potential error conduction might occur - are there cases in which a supporting function or actor will fail to respond appropriately? for example, a user action awaits a response but the function that is to respond times out - can poor system performance result in unexpected or improper user actions? for example, a web-based interface responds too slowly, resulting in a user making multiple selects on a processing button.

class-based elements

each usage scenario implies a set of objects that are manipulated as an actor interacts with the system. these objects are categorized into classes - a collection of things that have similar attributes and common behaviors.

software engineering framework

encompasses a process, a set of methods, and an array of tools

Process Framework

establishes the foundation for a complete software engineering process by identifying a small number of framework activities that are applicable to all software projects, regardless of their size or complexity. in addition, the process framework encompasses a set of umbrella activities that are applicable across the entire software process.

data modeling concepts

if software requirements include the need to create, extend, or interface with a database or if complex data structures must be constructed and manipulated, the software team may choose to create a data model as part of overall requirements modeling. a software engineer or analyst defines all data object that are processed within the system, the relationships between the data objects, and other information that is pertinent to the relationships. the entity-relationship diagram ERD addresses these issues and represents all data objects that are entered stored transformed and produced within an application.

scenario-based modeling

if you understand how end users want to interact with a system, your software team will be better able to properly characterize requirements and build meaningful analysis and design models. Hence, requirements modeling with UML begins with the creation of scenarios in the form of use cases, activity diagrams, and swim-lane diagrams.

negotiating requirements

in an ideal requirements engineering context, the inception, elicitation, and elaboration tasks determine customer requirements in sufficient detail to proceed to subsequent software engineering activities. but this rarely happens. in reality, you may have to enter into a negotiation with one or more stakeholders. in most cases, stakeholders are asked to balance functionality, performance, and other product or system characteristics against cost and time-to-market. the intent of this negotiation is to develop a project plan that meets stakeholder needs while at the same time reflecting the real-world constraints that have been placed on the software team. the best negotiations strive for a win-win result. that is stakeholders winning the system or product hat satisfies the majority of their needs and you win by working to realistic and achievable budgets and deadlines. Boehm defines a set of negotiation activities at the beginning of each software process iteration. rathe than a single customer communication activity, the following activities are defined: (1) identification of the system or subsystem's key stakeholders (2) determination of the stakeholders win conditions (3) negotiation of the stakeholders win conditions to reconcile them into a set of win-win conditions for all concerned. successful completion of these initial steps achieves a win-win result, which becomes the key criterion for proceeding to subsequent software engineering activities.

if the project is more complex, communication activity might have six distinct actions

inception elicitation elaboration negotiation specification validation each actions would have many tasks and number of distinct work products

flow-oriented elements

information is transformed as it flows through a computer-based system. the system accepts input in a variety of forms, applies functions to transform it, and produces output in a variety of forms. input may be a control signal transmitted y a transducer, a series of numbers typed by a human operator, a packet of information transmitted on a network link, or a voluminous data file retrieved from secondary storage. the transform may compromise a single logical comparison, a complex algorithm, or rule-inference approach. in effect, we create a flow model for any computer-based system regardless of size and complexity.

input and output for domain analysis

input - technical literature - existing applications - customer surveys - expert advice - current/future requirements output - class taxonomies - reuse standards - functional models - domain languages

requirements engineering: specification

int he context of computer-based systems, the team specification means different things to different people. A specification can be a written document, set of graphical models, a formal mathematical model, a collection of usage scenarios, a prototype, or any combination of these. some suggest a "standard template" be developed and used for a specification, arguing that this leads to requirements that are presented in a consistent and therefore more understandable manner. however, it is sometimes necessary to remain flexible when a specification is to be developed. For large systems, a written document, combining natural language descriptions and graphical models may be the best approach.

DDD domain-driven design

is an improvement on the "system metaphor" concept used in CP. Suggests the evolutionary creation of a domain model that "accurately represents how domain experts think about their subject".

requirements engineering: negotation

it isn't unusual for customers and users to ask for more than can be achieved, given limited business resources. it is also relatively common for different customers or users to propose conflicting requirements, arguing that their version is "essential for our special needs" you have to reconcile these conflicts through a process of negotiation. customers, users, and other stakeholders are asked to rank requirements and then discuss conflicts in priority. using an iterative approach that prioritizes requirements, assesses their cost and risk, and addresses internal conflicts, requirements are eliminated, combined, and/or modified so that each party achieves some measure of satisfaction.

requirements engineering: elicitation

it seems simple enough - ask the customer, the users, and others what the objectives for the system or product are, what is to be accomplished, how the system or product fits into the needs of the business, and finally, how the system or product is to be used on a day-to-day basis. but its not so simple - its very hard. problems encountered as elicitation occurs: - problems of scope - problems of understanding - problems of volatility

Myths

management myths customer myths practitioner myths see page 22

collaborative requirements gathering

many different approaches to collaborative requirements gathering have been proposed. each makes use of a slightly different scenario but all apply some variation on the following basic guidelines: - meetings are conducted and attended by both software engineers and other stakeholders - rules for preparation and participation are established - an agenda is suggested that is formal enough to cover all important points but informal enough to encourage the free flow of idea - a facilitator (can be customer, develop, outsider) control the meetings - a definition mechanism (can be work sheets, flip charts, wall sticker, bulletin board, chat room, or virtual forum) is used the goal is to identify the problem, propose elements of the situation, negotiate different approaches, and specify a preliminary set of solution requirements in an atmosphere that is conducive to the accomplishment of the goal.

defining operations

operations define the behavior of an object. although many different types of operations exists, they can generally be divided into four broad categories: (1) operations that manipulate data in some way (2) operations that perform a computation (3) operations that inquire about the state of an object (4) operations that monitor an object for the occurence of a controlling event.

what are the elements of a software process?

process, activity, action, task

class-based modeling

represents the objects the system will manipulate, the operations applied to the objects, relationships and collaboration between objects, and collaborations that occur between the classes. the elements of a class based model include classes and objects, attributes, operations, class responsibility-collaborator (CRC) models, collaboration diagrams, and packages.

requirements engineering

requirements engineering provides the appropriate mechanism for understanding what the customer wants, analyzing need, assessing feasibility, negotiating a reasonable solution, specifying the solution unambiguously, validating the specification, and managing the requirements as they are transformed into an operational system. It encompasses seven distinct tasks: (1) inception (2) elicitation (3) elaboration (4) negotiation (5) specification (6) validation (7) management

Requirements Management

requirements for computer-based systems change, and the desire to change requirements persists throughout the life of the system. requirements management is a set of activities that help the project team identify, control, and track requirements and changes to requirements at any tie as the project proceeds. many of these activities are identical to the software configuration management techniques discussed in chapter 22.

Requirements Analysis

results in the specification of software's operational characteristics, indicates software's interface with other system elements, and establishes constraints that software must meet. requirements analysis allows you to elaborate on basic requirements established during the inception, elicitation, and negotiation tasks that are part of requirements engineering the requirements modeling actions results in one or more of the following types of models: - scenario-based models - data models - class-oriented models - flow-oriented models - behavioral models

domain analysis

software domain analysis is the identification, analysis, and specification of common requirements form a specific application domain, typically for reuse on multiple projects within that application domain.

activity

strives to achieve a broad objective and is applied regardless of the application domain, size of the project, complexity of the effort, or degree of rigor with which software engineering is to be applied.

Swimlane diagrams

the UML swimlane diagram is a useful variation of the activity diagram and allows you to represent the flow of activities described by the use case and at the same time indicate which actor or analysis class has responsibility for the action described by an activity rectangle. responsibilities are represented as parallel segments that divide the diagram vertically, like the lanes in a swimming pool.

Behavioral elements

the behavior of a computer-based system can have a profound effect on the design that is chosen and the implementation approach that is applied. therefore, the requirements model must provide modeling elements that depict behavior. the "state diagram" is one method for representing the behavior of a system by depicting its states and the events that cause the system to change state. a state is any externally observable mode of behavior. in addition, the state diagram indicates actions taken as a consequence of a particular event.

Developing a Use Case

the first step in writing a use case is to define the set of "actors" that will be involved in the story. Actors are the different people (or devices) that use the system or product within the context of the function and behavior that is to be described. actors represent the roles that people or devices play as the system operates. defined somewhat more formally, an actor is anything that communicates with the system or product and that is external to the system itself. suggested questions to be answered by a use case? - who is the primary actor(s) and secondary actor(s) - what are the actor's goals - what preconditions should exist before the story begins - what main tasks or functions are performed by the actor - what exceptions might be considered as the story is described - what variations in the actor's interaction are possible - what system information will the actor acquire, produce, or change - will the actor have to inform the system about changes in the external environment - what information does the actor desire - does the actor wish to be informed about unexpected changes Safe Home example page 135

writing a formal use case

the informal use cases are sometimes sufficient for requirements modeling. however, when a use case involves a critical activity or describes a complex set of steps with a significant number of exceptions, a more formal approach may be desirable. the goal identifies the over scope of the use case. the precondition describes what is know to be true before the use case is initiated. the trigger identifies the event or condition that "gets the use case started" the scenario lists the specific actions that are required by the actor and the appropriate system responses. exceptions identify the situations uncovered as the preliminary use case is refined.

requirements engineering: elaboration

the information obtained from the customer during inception and elicitation is expanded and refined during elaboration. this task focuses on developing a refined requirements model that identifies various aspects of software function, behavior, and information. elaboration is driven by the creation and refinement of user scenarios that describe how the end user will interact with the system. each use scenario is parsed to extract analysis classes - business domain entities that are visible to the end user. the attributes of each analysis class are defined, and the services that are required by each class are identified. the relationships and collaborative between classes are identified, and a variety of supplementary diagrams are produced.

building the requirements model

the intent of the analysis model is to provide a description of the required informational, functional, and behavioral domains for a computer-based system. the model changes dynamically as you learn more about the system to be built, and other stakeholders understand more about what they really require. for that reason, the analysis model is a snapshot of requirements at any given time. you should expect it to change

Prototyping

the process of building a model that demonstrates the features of a proposed product, service, or system.

overall objectives and philosophy

the requirements model must achieve three primary objectives: (1) to describe what the customer requires, (2) to establish a basis for the creation of a software design, and (3) to define a set of requirements that can be validated once the software is built. the analysis model bridges the gap between a system-level description that describes overall system or business functionality as it is achieved by applying software, hardware, data, human, and other system elements and a software design that describes the software's application architecture, UI, and component-level structure.

scenario-based elements

the system is described from the user's point of view using a scenario-based approach. for example, basic use cases and their corresponding use-case diagrams evolve into more elaborate template-based use cases. scenario-based elements of the requirements model are often the first part of the model that is developed. as such, they serve as input for the creation of other modeling elements.

elicitation work products

the work products produced as a consequence of requirements elicitation will vary depending on the size of the system or product to be built. for most system, the work products include: - a statement of need and feasibility - bounded statement of scope for the system or product - a list of customers, users, and other stakeholders who participated in requirements elicitation - description of the system's technical environment - list of requirements and the domain constraints that apply to each - set of usage scenarios that provide insight into the use of the system or product under different operating conditions - any prototypes developed to better define requirements

requirements engineering: validation

the work products produced as a consequence of requirements engineering are assessed for quality during a validation step. requirements validation examines the specification to ensure that all software requirements have been stated unambiguously; that inconsistencies, omissions, and errors have bee detected and corrected; and that the work products conform to the standards established for the process, the project, and the product

identifying analysis classes

we can begin to identify classes by examining the usage scenarios developed as part of the requirements model and performing a "grammatical parse" on the use cases developed for the system to be built. classes are determined by underlining each noun or noun phrase and entering it into a simple table. synonyms should be noted. if the class (noun) is required to implement a solution, then it is part of the solution space, otherwise, if a class is necessary only to describe a solution, it is part of the problem space. analysis classes manifest themselves in one of the following ways: external entities that produce or consumer information to be used by a computer-based system - things that are part of the information domain for the problem - occurrences or events that occur within the context of the system operation - roles played by people ho interact with the system - organizational units that are relevant to an application - places that establish the context of the problem and the overall function of the system - structures that define a class of objects or related classes of objects

action

encompasses a set of tasks that produce a major work product

iterative process flow

repeats one or more of the activities before proceeding to the next

parallel process flow

executes one or more activities in parallel with other activities

Agile Design

- follows the keep it simple KIS principles. Simple is always preferred. - encourages use of CRC cards (class-responsibility-collaborator) - If a difficult design problem is encountered, XP recommends the immediate creation of an operational prototype of that portion of the design called spike solution - XP encourages refactoring - a construction technique that is also a method for design optimization -refactoring improves the internal structure of a design without changing its external functionality or behavior

Types of Process Models

- generic process model - prescriptive proces model - sequential process model - waterfall model - V model - incremental process model - evolutionary process model - prototyping - spiral model - concurrent process model - specialized model - formal methods model - aspect-oriented model - Personal and Team Models

points of software engineering

- it follows that a concerted effort should be made to understand the problem before a software solution is developed - it follows that design becomes a pivotal activity - it follows that software should exhibit high quality - it follows that software should be maintainable

Evolutionary process models

- iterative They are characterized in a manner that enables you to develop increasingly more complete software versions. includes prototyping and spiral model

what characteristics differentiate WebApps from other software? Characteristics of WebApps?

- network intensiveness - concurrency - unpredictable load - performance - availability - data driven - content sensitive - continuous evolution - immediacy - security - aesthetics

how do process models differ from one another?

- overall flow of activities, actions, and tasks and the interdependencies among them - degree to which actions and 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 with which the process is described - degree to which the customer and other stakeholders are involved with the project - level of autonomy given to the software team - degree to which team organization and roles are prescribed

what formal techniques are available for assessing the software process?

1. Standard CMMI Assessment Method for Process Improvement (SCAMPI) 2. SMM-Based Appraisal for Internal Process Improvement (CBA IPI) 3. SPICE (ISO/IEC15504) 4. ISO 9001:2000 for Software

Scrum emphasizes the uses of a set of software process patterns that have proven effective for projects with tight timelines, changing requirements, and business critically. Each of the process patterns defines a set of development actions:

1. backlog 2. sprints 3. scrum meetings 4. demos

what are five generic process framework activities?

1. communication 2. planning 3. modeling 4. construction 5. deployment

prototyping paradigm

1. communication with stakeholders to define the overall objectives for the software, identify whatever requirements are known, and outline areas where further definition is mandatory. \ 2. a prototyping iteration is planned quickly, and modeling occurs. A quick design focuses on a representation of those aspects of the software that will be visible to end users. 3. the quick design leads to the construction of a prototype. 4. The prototype is deployed and evaluated by stakeholders, who provide feedback that is used to further refine requirements.

Agility Principles

1. our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. welcome changing requirements, even late in development. agile processes hardness change for the customer's competitive advantage 3. deliver working software incrementally, from a couple of weeks to a couple of months, with a preference to the shorter timescale 4. business people and developers must work together daily throughout the project 5. build projects around motivated individuals. give them the environment and support they need, and trust them to get the job done 6. the most efficient and effective method of conveying information to and within a development team is face-to-face conversation 7. working software is the primary measure of progress 8. agile processes promote sustainable development. the sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. continuous attention to technical excellence and good design enhances agility 10. simplicity - the art of maximizing the amount fo work not done - is essential 11. the best architectures, requirements, and designs emerge from self-organizing teams 12. at regular intervals, the team reflects on how to become more effective, the tunes and adjusts its behavior accordingly.

IXP six new practices that are designed to help ensure that an XP project works successfully for significant projects within a large organization.

1. readiness assessment 2. project community 3. project chartering 4. test-driven management 5. retrospectives 6. continuous learning in addition, IXP modifies a number of existing practices: SDD story-driven development, DDD domain-driven design, pair programming, iterative usability

problems with the waterfall model

1. real projects rarely follow the sequential flow that the model proposes. Although the linear model can accommodate iteration, it does so indirectly. As a result, changes can cause confusion as the project team proceeds. 2. it is often difficult for the customer to state all requirements explicitly. The waterfall model requires this and has difficult accommodating the natural uncertainty that exists at the beginning of many projects. 3. the customer must have patience. A working version of the program will not be available until late in the project time span. A major blunder, if undetected until the working program is reviewed, can be disastrous. 4. the linear nature of the classic life cycle leads to "blocking states" in which some project team members must wait for other members of the team to complete dependent tasks.

Seven broad categories of computer software

1. system software 2. application software 3. engineering/scientific software 4. embedded software 5. product line software 6. web applications 7. artificial intelligence

David Hooker's seven principles that focus on software engineering as a whole

1. the reason it all exists 2. KISS (keep it simple, stupid!) 3. maintain the vision 4. what you produce, others will consume 5. be open to the future 6. plan ahead for reuse 7. think!

What types of changes are made to legacy systems? legacy systems evolve for the following reasons:

1. the software must be adapted to meet the needs of new computing environments or technology 2. the software must be enhanced to implement new business requirements 3. the software must be extended to make it interoperable with other more modern systems or databases 4. the software must be re-architected to make it viable within a network environment

adaptive software development (ASD)

A software development approach used when requirements cannot be clearly expressed early in the life cycle. Three phases - Speculation - adaptive cycle planning - mission statement - project constraints - basic requirements - time-boxed release plan - collaboration - requirements gathering - JAD - mini-specs - learning - components implemented/tested - focus groups for feedback - formal technical reviews - postmortems ASD emphasizes learning as a key element in achieving a "self-organizing" team

aspected-orientated software development (AOSD)

AKA aspect-oriented programming (AOP) provides a process and methodological approach for defining, specifying, designing and constructing aspects.

evolutionary process flow

Executes the activities in a "circular" manner. Each circuit through the five activities leads to a more complete version of the software.

Industrial XP

Joshua Kerievsky describes IXP as "an organic evolution of XP. It is imbued with XP's minimalist, customer-centric, test-driven spirit. IXP differs most from the original XP in its greater including of management, its expanded role for customers, and its upgraded technical practices"

V-Model

Like the waterfall model, but arranged in a V-shape, showing the relationship between an early phase and a testing phase. There is a greater emphasis on testing, and testing procedures are developed early on. as the software team moves down the left side of the V, basic problem requirements are refined into progressively more detailed and technical representatives of the problems and its solution. Once code has been generated, the team moves up the right side of the V, essentially performing a series of tests that validate each of the models created as the team moved down the left side.

principles that guide process:

P1: Be Agile P2: Focus on quality at every step P3: be ready to adapt P4: build an effective team P5: establish mechanisms for communication and coordination P6: manage change P7: assess risk P8: create work products that provide value for others the following set of core principles can be applied to the framework, and by extension, to every software process

testing principles

P1: all tests should be traceable to customer requirements P2: tests should be planned long before testing begins P3: the Pareto principles applies to software testing P4: testing should begin "in the small" and progress toward testing "in the large" P5: exhaustive testing is not possible Glen Myers states a number of rules that can serve well as testing objectives: - testing is a process of executing a program with intent of finding an error - a good test case in one that has a high probability of finding an as-yet-undiscovered error - a successful test is one that uncovers an as-yet-undiscovered error

deployment principles

P1: customer expectations for the software must be managed P2: a complete delivery package should be assembled and tested P3: a support regime must be established before the software is delivered P4: a appropriate instructional materials must be provided to end users P5: buggy software should be fixed first, delivered later the delivered software provides benefit for the end users, but it also provides useful feedback fro the software team. as the increment is put into use, end users should be encouraged to comment on features and functions, ease of use, reliability, and other characteristics that are appropriate.

design modeling principles

P1: design should be traceable to requirements model P2: always consider the architecture of the system to be built P3: design of data is as important as design is processing functions P4: interfaces (both internal and external) must be designed with care P5: user interface design should be tuned to the needs of the end user. However, in every case, it should stress ease of use P6: component-level design should be functionally independent P7: components should be loosely coupled to one another and to the external environment P8: design representations (models) should be easily understandable P9: the design should be developed iteratively. With each iteration, the designer should strive for greater simplicity. the software design model is analogous to an architect's plan for a house. it begins by representing the totality of the thing to be built and slowly refines the thing to provide guidance for constructing each detail. Similarly, the design model that is created for software produces a variety of different views of the system.

principles that guide practice:

P1: divide and conquer P2: understand the use of abstraction P3: strive for consistency P4: focus on the transfer of information P5: build software that exhibits effective modularity P6: look for patterns P7: when possible, represent the problem and its solution from a number of different perspectives P8: remember that someone will maintain the software these principles are not all you'll need to build high-quality software, bu they do establish a foundation for every software engineering method discussed in the book

communication principles:

P1: listen P2: prepare before you communicate P3: someone should facilitate the activity P4: face-to-face communication is best P5: take notes and document decisions P6: strive for collaboration P7: stay focused; modularize your decision P8: if something is unclear, draw a picture P9: (a) once you agree to something, move on (b) if you can't agree on something, move on (c) if a feature or function is unclear and cannot be clarified at the moment, move on P10. negotiation is not a contest or a game. it works best when both parties win effective communication is among the most challenging activities that you will confront.

requirements modeling principles

P1: the information domain of a problem must be represented and understood P2: the functions that the software performs must be defined P3: the behavior of the software (as a consequence of external events) must be represented P4: the models that depict information, function, and behavior must be partitioned in a manner than uncovers detail in a layered (or hierarchical) fashion P5: the analysis tasks should move from essential information toward implementation detail each analysis method has a unique point of view. However, all analysis methods are related by a set of operational principles stated above.

modeling principles

P1: the primary goal of the software team is the build software, not create models P2: travel light - don't create more models than you need P3: strive to produce the simplest model that will describe the problme or the osftwware P4: build models in a way that makes them amenable to change P5: be able ot state an explicit purpose for each model that is created P6: adapt the models you develop to the system at hand P7: try to build useful models, but forget about building perfect models P8: don't become dogmatic about the syntax of the mode. if communicates content successfully, representation is secondary. P9: if you instincts tell you a model isn't right even though it seems okay on paper, you probably have reason to be concerned P10: get feedback as soon as you can Scott Ambler and Ron Jeffries define a set of modeling principles that are intended for those who use agile process model but are appropriate for all software engineers who perform modeling actions and tasks.

planning principles

P1: understand the scope of the project P2: involve stakeholders in the planning activity P3: recognize that planning is iterative P4: estimate based on what you know P5: consider risk as you define the plan P6: be realistic P7: adjust granularity as you define the plan P8: define how you intend to ensure quality P9: describe how you intend to accommodate change P10. track the plan frequently and make adjustments as required to be most effective, everyone on the software team should participate in the planing activity. only then will team members "sign up" to the plan

George Polya's book 'How to Solve It'

The Essence of Practice 1. understand the problem (communication and analysis) - who has a stake in the solution to the problem? Who are the stakeholders? - what are the unknowns? what data, functions, and features are required to properly solve the problem? - ca the problem be compartmentalized? is it possible to represent smaller problems that may be easier to understand? - can the problems be represented graphically? can an analysis model be created? 2. plan a solution (modeling and software design) - have you seen similar problems before? are there patterns that are recognizable in a potential solution? - has a similar problem been solved? If so, are elements of the solution reusable? - can subproblems be defined? if so, are solutions readily apparent? - can you represent a solution in a manner that leads to effective implementation? can a design model be created? 3. carry out the plan (code generation) - does the solution conform to the plan? is source code traceable to the design model? - is each component part of the solution provably correct? 4. examine the result for accuracy (testing and quality assurance) - is it possible to test each component part of the solution? - does the solution produce results that conform to the data, functions, and features that are required?

Agile Testing

Unit test before coding is a key element of XP approach. - unit tests should be implemented using a framework that enables them to be automated. This encourages a regression testing strategy whenever code is modified. Wells states "fixing small problems every few hours takes less time than fixing huge problems just before the deadline" XP acceptance tests also called customer tests are specified by the customer and focus on overall system features and functionality that are visible and reviewable by the customer. Acceptance tests are derived from the user stories that have been implemented as part of a software release.

Pair programming (XP)

XP recommends that two people work together at one computer workstation to create code for a story. this provides a mechanism for real-time problem solving and real-time quality assurance. - it also keeps the developers focused on the problem at hand. - as pair programmers complete their work, the code they develop is integrated with the work of others. Sometimes this is performed daily by an integration team. Sometimes the pair paramours have to do it themselves. - this "continuous integration" strategy helps to avoid compatibility and interfacing problems and provides a "smoke testing" environment.

The XP Process

XP uses an object-oriented approach as its preferred development paradigm and encompasses a set of rules and practices that occur within the context of four framework activities: planning, design, coding, and testing.

Extreme Programming (XP)

a method for developing software applications and information system projects in which the project is divided into smaller functions and developers can not go on to the next phase until the current phase is finished. Each function of the overall project is developed in a step-by-step fashion. the most widely-used process model to agile software development

what is a process pattern?

a process pattern describes a process-related problem that is encountered during software engineering world, identifies the environment in which the problem has been encountered, ad suggest one or more proven solutions to the problem. In more general terms a process pattern provides you with a template -- consistent method for describing problem solutions within the context of the software process. Pattern Name: i.e. requirementsunclear Intent. Type: i.e. phase pattern or stage pattern Initial context: problem: solution: resulting context: related patterns: known uses and examples: see page 37 for example

Scrum

an agile development method conceived by Jeff Sutherland and his team in the 1990s. Scrum principles are consistent with agile manifesto and incorporates following framework activities: requirements, analysis, design, evolution, and delivery. Within each framework activity, work tasks occur within a process pattern called a sprint. page 83

Dynamic Systems Development Method DSDM

an agile software development process model that "provides a framework for building and maintaining systems which meet tight time constraints through the use of incremental prototyping in a controlled project environment." - iterative software process in which each iteration follows the 80% rule. that is, only enough work is required for each increment to facilitate movement to the next increment. The remaining detail can be completed later when more business requirements are known or changes have been requested and accommodated. borrowed from a modified version of the Pareto principle -- 80% of an application can be delivered in 20% of the time it would take to deliver the complete application 100%

incremental process models

combines elements of linear and parallel process flows discussed in section 2.1. referring to figure 2.5, the incremental model applies linear sequences in a staggered fashion as calendar time progresses. Each linear sequence produces deliverable "increments" of the software in a manner that is similar to the increments produced by an evolutionary process flow. The first increment is usually the core product.

task set

defines the actual work to be done to accomplish the objectives of a software engineering action for a small, relatively simple project, the task set might look like this: 1. make a list of stakeholders for the project 2. invite all stakeholders to an informal meeting 3. ask each stakeholder to make a list of features and functions required 4. discuss requirements and build a final list 5. prioritize requirements 6. note areas of uncertainty for a larger, more complex soft ware project, work tasks might look like this: 1. make a list of stakeholders for the project 2. interview each one separately to determine overall wants and needs 3. build a preliminary list of functions and features based on stakeholder input 4. schedule a series of facilitated application specification meetings 5. conduct meetings 6. produce informal user scenarios as part of each meeting 7. refine user scenarios based on stakeholders feedback 8. build a revised list of stakeholder requirements 9. use a quality function deployment technique to prioritize information 10. package requirements so that they can be delivered incrementally. discuss methods for validating system

process flow

describes how the framework activities and the actions and tasks that occur within each framework activity are organized with respect to sequence and time - linear - iterative - evolutionary - parallel see page 33

Iterative usability

discourages front-loaded interface design in favor of usability design that evolves as software increments are delivered and users interaction with the software is studied.

task

focuses on a small, but well-defined objected that produces a tangible outcome

Team Software Process (TSP)

goal of TSP is to build a "self directed" project team that organizes itself to produce high-quality software. Watts Humphrey defines the following objectives for TSP: - build self-directed teams that plan and track their work, establish goals, and own their processes and plans. These can be pure software teams or integrated product teams of 3 to about 20 engineers. - show managers how to coach and motivate their teams and how to help them sustain peak performance - accelerate software process improvement by making CMM Level 5 behavior normal and expected - provide improvement guidance to high-maturity organizations - facilitate university teaching of industrial-grade team skills TSP defines the following framework activities: project launch high-level design implementation integration and test postmortem

Software process framework

has an umbrella activities set - contains framework activity framework activity contains software engineering actions actions contain - task sets tasks contain - work tasks - work products - quality assurance points - project milestones

process technology tools

have been developed to help software organizations analyze their current process, organize work tasks, and control and monitor progress, and manage technical quality. they allow a software org to build an automated model of the process framework, tasks sets, and umbrella activities discussed in Section 2.1. The model, normally represented as a network, can then be analyzed to determine typical workplace and examine alternative process structures that might lead to reduced development time or cost.

component-based development

incorporates many of the characteristics of the spiral mode. it is evolutionary in nature, demanding an iterative approach to the creation of software. However, the component development model constructs applications from prepackaged software components. 1. available component products are research and evaluated for the application domain in question 2. component integration issues are considered 3. a software architecture is designed to accommodate the components 4. components are integrated into the architecture 5. comprehensive testing is conducted to ensure proper functionality

continual adaptation without forward progress accomplishes little. Therefore, an agile software process must adapt...

incrementally. To accomplish incremental adaptation, an agile team requires customer feedback. An effective catalyst for customer feedback is a prototype.

SDD Story-driven development

insists that stories for acceptance tests be written before a single line of code is generated

Agility

is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. - Agility means effective (rapid and adaptive) response to change, effective communication among all stockholder. - Drawing the customer onto team and organizing a team so that it is in control of work performed. - The Agile process, light-weight methods are People-based rather than plan-based methods. - The agile process forces the development team to focus on software itself rather than design and documentation. - The agile process believes in iterative method. - The aim of agile process is to deliver the working model of software quickly to the customer For example: Extreme programming is the best known of agile process.

New challenges for software engineers

open world computing net-sourcing open source

Crystal

page 86

Lean Development software LSD

page 87

Agile Modeling AM

page 88

Agile Unified Process AUP

page 89

Agile planning

planning - starts with listening which leads to user stories - each tory is written by customer and placed on index card - customer assigns a value to the story based on the business functions - members of XP team assign a cost - commitment is made for release - after first project release, XP team computes project velocity - developed and delivered in increments - functionality of these increments is not planned in advance but is decided during the development - customer's priorities and requirements change so it makes sense to have a flexible plan

coding principles

preparation principles: before you write one line of code, be sure you: - understand the problem - understand basic design pricnoles and concepts - pick a programming language that meets the needs of the software and environment - select a prograamming environment that provides tool tha tmake work easier - create a set of unit tests that will be applied once the component you code is completed programming principles: as you begin writing code, be sure you: - constrain your algorithms by following structured programming language - consider the use of pair programming - select data structures that will meet the needs of the design - understand the software architecture and create interface that are consistent with it - keep conditional logic as simple as possible - created nested loops in a way that makes them easily testible - write code that is self-documeting - create a visual layout validation principles: after you've completed your first coding pass, be sure you: - conduct a code walkthrough when appropriate - perform unit tests and correct errors you've uncovered - refactor the code

defining software

software is: (1) instructions (computer programs) that when executed provide desired features, function, and performance; (2) data structures that enable the programs to adequately manipulate information, and (3) descriptive information in both hard copy and virtual forms that describes the operation and use of the programs

typical umbrella activities include

software project tracking and control risk management software quality assurance technical reviews software configuration management reusability managment work product preparation and production

concurrent development model

sometimes called concurrent engineering, allows a software team to represent iterative and concurrent elements of any of the process models described in this chapter. for example, the modeling activity defined for the spiral model is accomplished by invoking one or more of the following software engineering actions: prototyping, analysis, and design. concurrent modeling defines a series of events that will trigger transitions from state to state for each of the software engineering activities, actions, or tasks.

Waterfall Model

sometimes called the classic lifecycle mode, suggest a systematic approach to software development that begins with customer specification of requirements and progresses through planning, modeling, construction, and deployment, culminating in ongoing support of the completed software.

construction principles

the construction activity encompasses a set of coding and testing tasks that lead to operational software that is ready for delivery to the customer or end suer. In modern software engineering world, coding may be (1) the direct creation of programming language source code, (2) the automatic generation f source code using an intermediate design-like representation of the component to be built, or (3) the automatic generation of executable code using a "fourth-generation programming language" e.g. visual C++ initial focus of testing is at the component level, is called unit testing. other levels of testing include: (1) integration testing (conducted as the system is constructed), (2) validation testing that assesses whether requirements have been met for the complete system (or software increment), and (3) acceptance testing that is conducted by the customer in an effort to exercise all required features and functions.