INF305

Yellow = answered textbook questions Blue = unanswered questions

Chapter 3 Process Models

Prescriptive process models prescribe a set of process elements: Framework activities, tasks, work products, quality assurance Generic framework activities: Communication Planning Modeling Construction Deployment Linear process model: 1. Waterfall model (Classic life cycle) Systematic, linear, sequential approach For projects with these characteristics: o The problem is well understood (well-defined requirements) o The delivery date is realistic o Major changes in requirements are unlikely For when work flows in a reasonably linear fashion The linear nature can lead to blocking states, where you have to wait for other team members to complete dependent tasks Inappropriate model for todays fast-paced changing software Problems: o Real projects rarely follow a sequential flow o The customer has to state all requirements explicitly o Working version of the program appears late in the project Software projects that would be amenable to the waterfall model: o A well-understood modification to an existing program o A straightforward implementation of a numerical calculation or business rule, even if it is complex o A constrained enhancement to an existing program Incremental process models: For when requirements are well-defined, and a limited set of software functionality must be provided quickly, and then refined later. 2. Incremental model Combines elements of the waterfall model applied iteratively Linear sequences each produce deliverable increments of software The first increment is usually a core product, used by customers Each increment focuses on the delivery of an operational product Good when staffing is unavailable for a complete implementation Increments can be planned to manage technical risks Software projects amenable to the incremental model: o A project that has significant functionality that must be delivered in a very tight time frame (Add on extras later) 1

3. RAD model An incremental model that emphasizes a short development cycle A high-speed adaptation of the waterfall model, where rapid development is achieved by using component-based construction For when requirements are understood and scope is constrained For when business applications can be modularized A fully functional system is constructed in a very short time Each major function is addressed by a separate RAD team and then integrated to form a whole To achieve rapid development, this model assumes the existence of: a project that can be modularized in a manner that allows major functionality to be delivered within 60-90 days (This isnt always the case sometimes timelines can be longer) Drawbacks: For large projects, RAD requires sufficient human resources to develop the increments in parallel Projects will fail if people dont commit to rapid activities If a system cant be modularized, you cant build components Might not work if high performance is an issue Might not be appropriate when technical risks are high Evolutionary process models: For when core requirements are well understood and a limited version of the product must be introduced, which will evolve over time. Iterative, and can easily accommodate product requirement changes. 4. Prototyping For when the customer defines a set of general objectives For when the developer is unsure of the form of the software Can be used as a standalone process model, but is more commonly used as a technique that can be implemented within other models The prototype helps to identify software requirements It should be discarded (at least in part) Problems with prototyping: o The customer sees a working version and wants to keep it o Developers may become comfortable with inefficient choices Software projects amenable to the prototyping model: o Ones which involve human-machine interaction and/or heavy computer graphics o Ones where results can easily be examined without real-time interaction (e.g. command-driven systems using mathematical algorithms) i.e. not embedded software! Process adaptations required if the prototype will evolve into a deliverable system / product: o More rigorous design rules and SQA procedures must be applied from the beginning 2

o The prototype must be designed with extensibility in mind and be implemented using a programming environment that is amenable to production system development o The prototype is initially a mechanism for identifying requirements, and then becomes the framework for extensions that will cause it to evolve into a production system 5. Spiral model Combines the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model Rapid development of increasingly complete versions of software Software is developed in a series of evolutionary releases Each framework activity represents 1 segment of the spiral path Risk-driven model: risk evaluation during each iteration Anchor point milestones are noted for each evolutionary pass This model can apply throughout the life of the software Good for developing large-scale systems and software Not good if you have a fixed budget, because project cost is revised as each circuit is completed Prototyping reduces risks, and can be applied at any stage Problems: o May be hard to convince customers that its controllable o Demands considerable risk assessment and expertise o Problems if a major risk is not uncovered and managed What happens to the software as you move outwards along the spiral process flow: o The product moves towards a more complete state o The level of abstraction at which work is performed is reduced (i.e. implementation-specific work accelerates as we move further from the origin) 6. Concurrent development model Represented as a series of framework activities, software engineering actions & tasks, and their associated states All activities exist concurrently but reside in different states What the states represent and how they come into play: o The different parts of a project (framework activities) will be at different stages of completeness (e.g. under development, awaiting changes, done), so you can say that all activities are being performed concurrently o The challenge is to manage the concurrency and to be able to assess the status of the project A series of events are defined that will trigger transitions from state to state for each of the software activities / tasks This model is applicable to all types of software development Often used for the development of client/server applications Provides an accurate picture of the current state of the project 3

Weaknesses of process models: Prototyping poses a problem to project planning because of the uncertain number of cycles required to construct the product Evolutionary processes dont establish the maximum speed of the evolution Software processes should be focused on flexibility and extensibility rather than on high quality Specialized process models: For when a narrowly defined software engineering approach is chosen. 7. Component-based development model Incorporates many characteristics of the spiral model, but composes applications from prepackaged software components Works best when object technologies are available for support These steps are implemented using an evolutionary approach: 1. Available products are evaluated for the application domain 2. Component integration issues are considered 3. A software architecture is designed 4. Components are integrated into the architecture 5. Comprehensive testing is conducted to ensure functionality Benefit: Leads to software reuse Software projects amenable to the component-based model: o Ones where COTS components are available o If the interfaces for the available components are compatible with the architecture of the system to be built 8. Formal methods model Formal mathematical specification of computer software Ambiguity, incompleteness, and inconsistency are easily found Offers the promise of defect-free software Reasons why it is not widely used: o Time-consuming and expensive o Extensive training o Difficult to use the models to communicate with customers Good for safety-critical software (aircraft avionics, medical) 9. Aspect-oriented software development Software has localized features, functions, and information These localized characteristics are modeled as components and then constructed within the context of a system architecture Discuss the meaning of crosscutting concerns: o Concerns (e.g. security, fault tolerance) that cut across multiple system functions, features and information Aspectual requirements define those crosscutting concerns that have impact across the software architecture Aspects = localizing the expression of a crosscutting concern 4

10. The Unified Process Recognizes the importance of customer communication (use cases) Emphasizes the important role of software architecture Suggests an iterative, incremental process flow The difference between the UP and UML: o UML = a modeling notation and language o UP = a process framework in which UML may be applied as part of SE activities Phases of the Unified Process: 1. Inception Customer communication and planning activities Identify software requirements, propose a rough architecture, and plan for the iterative, incremental nature of the project Use cases describe fundamental business requirements Work product: Use case model 2. Elaboration Customer communication and modeling activities Refines and expands the preliminary use-cases Expands architectural representation to include 5 views of the software: Use-case model, analysis model, design model, implementation model, and deployment model Work products: analysis model, design model 3. Construction Develop the software that will make each use-case operational Unit tests are designed and executed for each component Work products: implementation, deployment, and test models 4. Transition Encompasses later stages of construction & 1st part of deployment Beta testing by end-users to discover defects & deficiencies Support information is created (user manuals) Work product: the software increment (5.) Production Coincides with deployment On-going use of the software is monitored, support of the operating environment is provided, and defect reports and requests for changes are submitted and evaluated Workflows distributed across the UP phases: The difference between a UP phase and a UP workflow: o A workflow is distributed across all UP phases and identifies the tasks required to accomplish an action and the work products produced

Requirements Analysis Design Implement

Inception Use case model

Elaboration Analysis model Design model

Construction

Transition

Test

Implementation model Deployment model Test model

Is it possible to combine process models? o Yes, since they all perform the same set of generic framework activities What happens when we emphasize development speed over product quality: o The advantage of developing software in which quality is good enough is that it will meet the deadline o The disadvantage is that it may require more testing, design and implementation rework

Chapter 4 An agile view of process

Agility An agile team can respond appropriately to changes The skills of the team members and their ability to collaborate is at the core for the success of the project Dynamic, content specific, change embracing, and growth oriented Encourages team structures and attitudes that ease communication Emphasizes rapid delivery of operational software and deemphasizes the importance of intermediate work products Adopts the customer as a part of the development team Recognizes that a project plan must be flexible Can be applied to any software process 4 values of agile software development: 1. Individuals and interactions over processes and tools 2. Working software over comprehensive documentation 3. Customer collaboration over contract negotiation 4. Responding to change over following a plan Situations in which the 4 values can get a software team into trouble: 1. A project may fail because the processes & tools are poor 2. Documentation helps maintaining applications years later 3. Negotiation helps avoid unrealistic expectations 6

4. A chaotic project environment (no plan) can lead to failure 12 principles for achieving agility: 1. Main priority: early & continuous delivery of valuable software 2. Welcome changing requirements, even late in development 3. Deliver working software frequently 4. Business people & developers must work together daily 5. Build projects around motivated individuals 6. Face-to-face conversation with the development team 7. Working software is the primary measure of progress 8. Agile processes promote sustainable development 9. Continuous attention to technical excellence and good design 10. Simplicity 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, then tunes and adjusts its behavior accordingly Select one agility principle and try to determine whether each of the process models in this chapter exhibits the principle: o Welcome changing requirements, even late in development Change, with agile processes, is essential for competitive advantage, so all the models exhibit this principle Try to come up with another agility principle that would help a software engineering team become even more maneuverable: o A team should know whose skills suit a particular project and get these people on their project o Communication is the key: The customer and developer should communicate regularly, even if separated

Agile process Any agile software process is characterized by 3 key assumptions: 1. It is difficult to predict which software requirements will persist and which will change (priorities also change) 2. For many types of software, design and construction are interleaved, and 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 A process that can manage unpredictability must be adaptable It must adapt incrementally, using customer feedback An incremental development strategy should be instituted Software increments (e.g. prototypes) must be delivered in short time periods so that adaptation keeps pace with change Why does an iterative process make it easier to manage change? Is every agile process iterative? Is it possible to complete a project in just one iteration and still be agile? Explain. 7

o An iterative approach enables customers to evaluate regularly, provide feedback, and influence the required changes. (The software team manages change by focusing on a defined increment and postponing any changes until the next increment). All agile processes are iterative. If a project were completed in just one iteration it would not be agile because frequent software delivery is a key characteristic of agile development. Why do requirements change so much? o It is difficult to predict in advance which requirements will persist and which will change o It is difficult to predict how customer priorities will change as the project proceeds o It is difficult for customers to verbalize their software needs until they see a working prototype Describe agility for software projects: o Agility can be applied to any software process. The process must be designed in a way that allows the project team to Adapt tasks and to streamline them Conduct planning in a way that understands the fluidity of an agile development approach Eliminate all but the most essential work products Emphasize an incremental delivery strategy that gets software to the customer as rapidly as feasible Most agile process models recommend face-to-face communication. Yet today, members of a software team and their customers may be geographically separated from one another. Do you think this implies that geographical separation is something to avoid? Can you think of ways to overcome this problem? o Physical proximity is not always possible. Face-to-face communication can be achieved with low-cost video conferencing, Web-based discussion groups and other electronic means. These are not as powerful as physical proximity, but they can achieve much the same result.

Human factors: Key traits that must exist among the people on the software team: Competence Skill and knowledge of the process must be taught to the members Common focus Focus on the goal of delivering a working increment on time Collaboration Team members must collaborate with one another, with the customer, and with business managers to accomplish tasks Decision-making ability The team is given decision-making authority for project issues 8

Fuzzy problem-solving ability Deal with ambiguity and change, learning lessons from the past Mutual trust and respect A jelled team is strongly knit (whole > parts) Self-organization The team organizes 1. itself for the work to be done 2. the process to best accommodate the environment 3. the work schedule to best achieve delivery of the increment o Advantage: improves collaboration and boosts team morale

Agile process models 1. Extreme programming (XP) Uses an OO approach as its preferred development paradigm Planning Stories describe required features & functionality of software Each story is written by the customer & placed on an index card The customer assigns a value (priority) to the story Members of the XP team assess each story and assign a cost (measured in development weeks) If the story requires more than 3 weeks, the customer must split the story into smaller ones Customers and the XP team decide how to group stories into the next release (the next increment) Once a commitment is made for a release, the team orders the stories that will be developed in one of three ways: o All stories will be implemented immediately o The stories with highest value will be implemented first o The riskiest stories will be implemented first After the 1st release, the team computes project velocity (the number of customer stories implemented during the 1st release) Project velocity can then be used to: o Help estimate delivery dates & schedule for other releases o Determine whether an over-commitment has been made for all stories across the entire development project As work proceeds, the customer can add, change, split, or eliminate stories, and the team modifies its plans accordingly An XP story that describes the favorites feature of browsers: o Each URL that I intend to revisit can be stored in a favorite places file. I should be able to name and group URLs by categories that I define, store a favorite place in a particular category, order the URLs in any way I like and recall the favorite places file at any time from the browser menu. I should be able to list all favorite places as a categorized list in my browser window. I can select a favorite place using my mouse. Once selected, the browser will establish a link to that URL and display the website. 9

Design A simple design is always preferred over a complex one The design provides implementation guidance for a story (The design of extra functionality is discouraged) CRC cards identify and organize the OO classes that are relevant If a difficult design problem is encountered, create a prototype Spike solution = the prototype that is implemented & evaluated The only work products are CRC cards and spike solutions Refactoring = improving the code design after its been written Design occurs both before and after coding commences (Refactor!) Coding Develop unit tests to exercise each story before coding When the code is complete, it can be unit tested immediately Pair programming = having two people work together at one computer to create code for a story, for quality assurance As pair programmers complete their work, their code is integrated with the work of others, to uncover errors early This continuous integration provides a smoke testing environment Testing Tests should be automated to be executed easily & repeatedly Regression testing strategy whenever code is modified/refactored As the individual unit tests are organized into a universal testing suite, integration and validation testing of the system can occur on a daily basis This provides the team with a continual indication of progress Acceptance tests / customer tests = ones specified by customers and focus on overall features (stories) that are visible 2. Adaptive Software Development (ASD) Focuses on human collaboration and team self-organization Speculation The project is initiated & adaptive cycle planning is conducted Adaptive cycle planning uses the customers mission statement, project constraints, and basic requirements to define the set of release cycles that will be required Collaboration Motivated people work together in a way that multiplies their talent and creative output beyond their absolute numbers People working together must trust one another to o Criticize without animosity o Assist without resentment o Work as hard / harder as they do o Have the skill set to contribute to the work at hand o Communicate problems in ways that lead to effective action Learning ASD teams learn in 3 ways: 1. Focus groups 10

The customer / users provide feedback on software increments 2. Formal technical reviews ASD team members review the software components developed 3. Postmortems The team becomes introspective, addressing its own performance 3. Dynamic Systems Development Method (DSDM) Building systems which meet tight time constraints by using incremental prototyping in a controlled project environment Iterative process, but only enough work is required for each increment to facilitate movement to the next increment The remaining detail can be completed later Feasibility study (additional) Establishes the basic business requirements & constraints Assesses whether the application is a viable candidate for DSDM Business study (additional) Establishes the functional & information requirements Defines the basic application architecture and identifies the maintainability requirements for the application Functional model iteration (iterative) Produces a set of incremental prototypes for demonstration (All DSDM prototypes are intended to evolve into deliverables) Additional requirements are gathered by eliciting feedback from users as they exercise the prototype Design & build iteration (iterative) Revisits prototypes built during the functional model iteration to ensure that each will provide operational business value (The previous activity & this one can occur concurrently) Implementation (iterative) The latest software increment is placed into operation Note that the increment may not be 100% complete, and changes may be requested as the increment is put into place DSDM work continues by returning to the function model iteration 4. Scrum Small working teams are organized to maximize communication & knowledge, and minimize overhead The process must be adaptable to technical & business changes Frequent software increments Work and people are partitioned Constant testing and documentation A product is declared done whenever required Requirements analysis design evolution delivery Software process patterns define some development activities: o Backlog Prioritized list of project requirements / features Items can be added to the backlog at any time 11

o Sprints Work units that are required to achieve a requirement defined in the backlog that must fit into a time-box During the sprint, the backlog items it uses are frozen o Scrum meetings Short daily meetings where these key questions are asked: 1. What did you do since the last team meeting? 2. What obstacles are you encountering 3. What do you plan to accomplish by the next meeting? A scrum master assesses the responses from each person The meetings help the team uncover potential problems early These daily meetings lead to knowledge socialization o Demos Increment delivered to the customer so that functionality can be demonstrated and evaluated The demo maynt contain all planned functionality, but only the functions delivered within the established time-box A sample Scrum pattern: Pattern Scrum meeting Intent To answer three key questions using an abbreviated meeting format that is conducted daily Type Task pattern Initial 1. The project should have been initiated and a backlog context developed 2. Sprints should be underway 3. All members of the Scrum team should agree to meet in a pre-specified location each day for the scrum meeting 4. A team leader should be defined Problem It is often difficult for members of the team to understand the status of the project and the status of work being conducted by each member of the team. When meetings are conducted, they are often too time-consuming and ineffective. Solution Short meetings are held daily and the 3 key questions are asked and answered by all team members Resulting At the conclusion of the meeting, each person has answered context the questions noted in the solution Related Backlog preparation patterns Conducting a sprint Known uses Scrum meetings are conducted throughout every Scrum / examples project and are an important element of communication 5. Crystal An approach that puts a premium on maneuverability Primary goal: delivering useful, working software Secondary goal: setting up for the next game To achieve maneuverability, there is a set of methodologies to choose from, which all have core elements in common 12

Reflection workshops are conducted before, during, and after an increment is delivered Why Crystal is called a family of agile methods: o The Crystal approach emphasizes collaboration and communication among people who have varying degrees of interest in the software project. The method is also tolerant of varying team cultures and can accommodate both informal and formal SE approaches. Crystal family is actually a set of sample agile processes that have been proved effective for different types of projects. The intent is to allow agile teams to select the member of the Crystal family that is most appropriate for their project.

6. Feature Driven Development (FDD) A feature is a client-valued function that can be implemented in two weeks or less Benefits of the emphasis on the definition of features: o Because features are small, users can describe them more easily and better review them, and their design & code are easier to inspect effectively o Features can be organized into a hierarchy o The team develops operational features every two weeks o Project planning, scheduling, and tracking are driven by the feature hierarchy, rather than an arbitrarily adopted software engineering task set Five framework activities (processes): 1. Develop an overall model 2. Build a features list 3. Plan by feature 4. Design by feature 5. Build by feature FDD provides greater emphasis on project management guidelines and techniques than many other agile methods To determine if software increments are properly scheduled, FDD defines 6 milestones: design walkthrough, design, design inspection, code, code inspection, promote to build Use the FDD feature template to define a feature set for a Web browser, and develop a set of features for the feature set: (action) the (result) (by | for | of | to) a(n) (object) Examples: Specify a URL for a website Display the content of a website Fill in the content of a Web form Show all URLs for favorite places

7. Agile Modeling (AM) With large systems, scope and complexity must be modeled so that o All can better understand what needs to be accomplished 13

o The problem can be partitioned effectively among the people o Quality can be assessed at every step during engineering AM = a methodology for modeling & documentation of software in a light-weight manner: Agile models are barely good, not perfect AM provides guidance to practitioners during analysis & design An agile team must have the courage to make decisions and humility to recognize that they dont have all the answers Principles that make AM unique: o Model with a purpose Have a specific goal before creating the model o Use multiple models Each model should present a different aspect of the system o Travel light Keep only the models that will provide long-term value o Content is more important than representation Modeling should impart information to its intended audience o Know the models and the tools you use to create them Understand the strengths & weaknesses of each model & tool o Adapt locally Adapt the modeling approach to the needs of the agile team

Build a table that maps the generic framework activities into the activities defined for each agile process: Generic: XP ASD Scrum CommuniPlan (user stories) Speculation Requirements cation Collaboration Planning Plan (commit to a Speculation Analysis specific increment) (adaptive cycle planning) Modeling Design (refactoring, Collaboration Design spike solutions) (mini-specs) ConstrucCode (pair programming) Learning (learn Evolution tion Test (unit testing) as you develop components) Deployment Test (acceptance Learning Delivery testing, customer tests) Generic: Communication Planning FDD Develop an overall model Build a features list (features are grouped into sets) Plan by feature Design by feature (design package) Build by feature (completed function) DSDM Feasibility study (basic requirements) Business study (functional & info requirements) Functional model iteration (prototypes) Design & build iteration (revisit prototypes) Implementation

Modeling Construction Deployment

14

Chapter 5 Software engineering practice

Software engineering practice The essence of practice 1. Understand the problem (communication & analysis) Who are the stakeholders? What data, features, etc are needed to solve the problem? Can the problem be compartmentalized? Can an analysis model be created? 2. Plan a solution (modeling & software design) Have you seen similar problems before? Has a similar problem been solved? (Are elements reusable?) Can subprograms be defined? Can a design model be created? 3. Carry out the plan (code generation) Is source code traceable to the design model? Has the design and code been reviewed? 4. Examine the result for accuracy (testing & quality assurance) Has a reasonable testing strategy been implemented? Has the software been validated against all requirements? 7 Core principles Summarize David Hookers 7 principles for software development: 1. Software exists to provide value to its users 2. Keep it simple 3. Maintain the vision 4. What you produce, others will consume (maintain) 5. Be open to the future dont design yourself into a corner 6. Plan ahead for reuse 7. Think before you act Other technical essentials that can be recommended for SE: o The need to test software thoroughly to find errors o The need to use automated tools to facilitate development o The need to measure the product to improve quality Other management essentials that might be recommended for SE: o Continuous & effective communication with stakeholders o Implementation of an agile mindset o A set of management & technical practices that enable the team to define a road map as it travels towards its goal

1. Communication practices 1. Listen 2. Prepare before you communicate (e.g. an agenda) 3. Someone should facilitate the activity 4. Face-to-face communication is best 5. Take notes and document decisions 15

6. Strive for collaboration 7. Stay focused, modularize your discussion 8. If something is unclear, draw a picture 9. Move on after you agree / disagree / if something is unclear 10. Negotiation works best when both parties win Prepare a set of guidelines that focus solely on facilitation: o Understand the business domain o Know who the stakeholders are and what goals each has o Establish a defined requirements-gathering mechanism o Create a method for recording requirements o Establish a way to prioritize needs How should communication preparation manifest itself in the early work that you do? What work products might result? o Research the business domain that the software will address o Understand the stakeholders who will specify requirements o Develop a defined strategy for requirements gathering o Understand the goals for each of the stakeholders o Understand that negotiation will occur How does agile communication differ from traditional SE communication? How is it similar? o Why it is necessary to move on: o Sometimes people cant come to an agreement on some project-related issue, so rather than iterating endlessly, it is best to move on to achieve communication agility, leaving the topic for later

2. Planning practices 1. Understand the scope of the project 2. Involve the customer in the planning activity 3. Recognize that planning is iterative 4. Estimate (effort, cost, task duration) based on what you know 5. Consider risk as you define the plan (make contingency plans) 6. Be realistic (People make mistakes and dont work all day) 7. Adjust granularity as you define the plan 8. Define how you intend to ensure quality (FTR, pair programming) 9. Describe how you intend to accommodate change 10. Track the plan frequently and make adjustments as required What granularity means in the context of a project schedule: o Granularity refers to the level of detail that is introduced as a project plan is developed o Fine granularity plan: detail, planned over a short time o Coarse granularity plan: broad work tasks over long periods o Granularity goes fine coarse as the timeline moves on 16

3. Modeling practice Analysis modeling 1. The information domain (data in-out flows & stores) of a problem must be represented and understood 2. The functions that the software performs must be defined 3. The behavior of the software must be represented 4. The models that depict information, function, and behavior must be partitioned to uncover detail in a layered fashion 5. The analysis task should move from essential information towards implementation detail What three domains are considered during analysis modeling? o Informational, functional, and behavioral domains

Design modeling 1. Design should be traceable to the analysis model 2. Always consider the architecture of the system to be built 3. Design of data is as NB as design of processing functions 4. Interfaces (internal & external) must be designed with care 5. User interface design should be tuned to the needs of the user 6. Components should be highly cohesive 7. Components should be loosely coupled 8. Design representations (models) should be easy to understand 9. The design should be developed iteratively, striving for greater simplicity with each iteration Why models are important in SE work: o Models help us gain a better understanding of the actual entity to be built. Analysis models represent customer requirements, and design models provide a concrete specification for the construction of the software.

4. Construction practice Coding principles and concepts Preparation principles: 1. Understand the problem youre trying to solve 2. Understand basic design principles and concepts 3. Pick a suitable programming language 4. Select a suitable programming environment 5. Create a set of unit tests for when your component code is done Coding principles: 1. Constrain your algorithms by adhering to structured programming 2. Select data structures that will meet the needs of the design 3. Create interfaces that are consistent with the architecture 4. Keep conditional logic as simple as possible 5. Create nested loops in a way that makes them easily testable 6. Select meaningful variable names and follow coding standards 7. Write code that is self-documenting 8. The visual layout (new lines, indents) should aid understanding 17

Validation principles: 1. Conduct a code walkthrough when appropriate 2. Perform unit tests and correct errors youve uncovered 3. Refactor the code Testing principles 1. All tests should be traceable to customer requirements 2. Tests should be planned long before testing begins 3. Pareto principle: 80% of errors will be found in 20% of code 4. Testing should progress from in the small to in the large 5. Exhaustive testing is not possible What is a successful test? o One that has a high chance of finding an undiscovered error

5. Deployment Deployment encompasses three actions: o Delivery o Support o Feedback 1. Customer expectations for the software must be managed 2. A complete delivery package should be assembled and tested 3. A support regime must be established before the software is delivered 4. Appropriate instructional materials must be provided to users 5. Buggy software should be fixed first, delivered later Why feedback is important to the software team: o Feedback provides the software team with important guidance that results in modifications to the functions, features, and approach taken for the next increment

18

Chapter 7 Requirements engineering

Requirements engineering tasks 1. Inception Most projects begin when a business need is identified Stakeholders from the business community o define a business case for the idea o identify the breadth & depth of the market o do a rough feasibility analysis o identify a working description of the projects scope Software engineers ask a set of context-free questions to get a basic understanding of the problem, people, and type of solution Feasibility analysis within the context of inception: o Feasibility analysis identifies a working description of the projects scope and assesses whether or not that scope can be achieved within the context of management and technical constraints. It defines a business case for an idea and identifies the breadth & depth of the market.

2. Elicitation Why requirements elicitation is difficult: Problems of scope o The system boundary is ill-defined Problems of understanding o The customers are not completely sure what is needed o They dont know the capabilities & limitations of computers o They dont have a full understanding of the problem domain o They have trouble communicating their needs o They omit information that is believed to be obvious o They specify requirements that are ambiguous or untestable Problems of volatility o The requirements change over time 3. Elaboration The info from inception & elicitation is expanded & refined Driven by the creation and refinement of user scenarios that describe how the user will interact with the system Each user scenario is parsed to extract analysis classes Attributes & methods of each analysis class are identified Relationships between classes are identified UML diagrams End-result of elaboration: an analysis model that defines the informational, functional, and behavioral domain of the problem 4. Negotiation Possible conflicts: o Customers may ask for more than can be achieved o Different users may propose conflicting requirements Users must rank requirements and discuss conflicts in priority Risks associated with each requirement are analyzed 19

Rough estimates of development effort are made and used to assess the impact of each requirement on project costs and time Using an iterative approach, requirements are eliminated, combined, and/or modified so that each party is satisfied 5. Specification A specification can be a written doc, models, prototype, etc This is the final work product from the requirements engineer It describes the function, performance & constraints of a system 6. Validation Examine the specification to ensure that all requirements have been stated unambiguously, with errors & omissions corrected Formal technical review = the primary validation mechanism The review team includes software engineers, customers, users 7. Requirements management Activities that help the team identify, control and track requirements & changes at any time as the project proceeds Requirements are identified, and traceability tables are made: o Features traceability table Shows how requirements relate to important features o Source traceability table Identifies the source of each requirement o Dependency traceability table Indicates how requirements are related to one another o Subsystem traceability table Categorizes requirements by the subsystems they govern o Interface traceability table Shows how requirements relate to internal & external system interfaces 1. Inception: Initiating the requirements engineering process Identifying the stakeholders At inception, create a list of people who will contribute input as requirements are elicited The initial list will grow as stakeholders are contacted Recognizing multiple viewpoints There are different kinds of stakeholders, with different views As information from multiple viewpoints is collected, emerging requirements may be inconsistent / conflict with one another All stakeholder info must be categorized in a way that will allow decision-makers to choose a consistent set of requirements Working towards collaboration Stakeholders must collaborate among themselves The requirements engineer identifies commonality/conflict areas Asking the first questions Questions asked at inception should be context-free: o Who is behind the request for this work? 20

Who will use the solution? What will be the economic benefit of a successful solution? Is there another source for the solution that you need? Who is paying for this work? Who can we contact in each customer group? Do you know of any other business that has solved this problem successfully? These questions help identify stakeholders & project benefits The next set of questions enables the team to better understand the problem and allows the customer to voice his perceptions: o How would you characterize good output? o What problems will this solution address? o Can you describe the business environment? o Will special performance issues affect the solution? The final set of questions focuses on the effectiveness of the communication activity itself: o Are you the right person to answer these questions? o Are my questions relevant to the problem that you have? o Am I asking too many questions? o Can anyone else provide additional information? o Should I be asking you anything else? These questions help to break the ice & initiate communication The Q&A session should be used for the first encounter only and then replaced by a requirements elicitation format

o o o o o o

2. Eliciting requirements Collaborative requirements gathering Basic guidelines for a collaborative requirements meeting: o Meetings are conducted & attended by both software engineers and customers (and other stakeholders) o Rules for preparation and participation are established o An agenda is suggested o A facilitator controls the meeting o A definition mechanism (work sheets / flip charts / chat room / bulletin board / wall stickers) is used o The goal is to identify the problem, propose elements of the solution and a preliminary set of solution requirements Quality function deployment QFD = a technique that translates the needs of the customer into technical requirements for software Concentrates on maximizing customer satisfaction QFD identifies 3 types of requirements: o Normal requirements Reflect objectives stated for the system E.g. specific system functions, levels of performance o Expected requirements Implicit to the system, and not stated explicitly E.g. ease of use and installation 21

o Exciting requirements Features that go beyond the customers expectations E.g. Extra features that are pleasing & unexpected Function deployment is used to determine the value of each function that is required for the system Information deployment identifies both the data objects and events that the system must consume and produce Task deployment examines the behavior of the system within the context of its environment Value analysis is conducted to determine the relative priority of requirements determined during each of the three deployments QFD uses interviews & observation, surveys, and examination of historical data as raw data for requirements gathering Customer voice table = a table of requirements from this data User scenarios As requirements are gathered, an overall vision of system functions & features begins to materialize You must first understand how these functions & features will be used by different classes of end-users before getting technical To achieve this developers & users can create a set of scenarios (use cases) that identify a thread of usage for the system Elicitation work products Info that can be produced as a result of requirements gathering: o A statement of need and feasibility o A bounded statement of scope for the system o A list of stakeholders who participated in the elicitation o A description of the systems technical environment o A list of requirements and each ones domain constraints o A set of usage scenarios o Any prototypes developed to better define requirements Some problems that occur when requirements must be elicited from three or four different customers: o Problems of understanding, scope, and volatility o Each customer has his own priorities and views which may conflict with those of other customers What to do when eliciting requirements from a customer who is too busy to meet: o Write a memo outlining to the customer the objectives of the system to be developed. Objectives should be explained by the customer. o The QFD approach uses interviews, surveys, historical data as raw data for gathering requirements, which can be translated into a table of requirements: the customer voice table, that is reviewed with the customer. Diagrams, matrices, and evaluation methods are then used to extract the expected requirements. 22

Developing use-cases Primary actors interact to achieve required system function and derive the intended benefit from the system Secondary actors support the system so that primary actors can do their work Questions that should be answered by a use-case: o Who are the primary actor(s), secondary actor(s)? o What are the actors goals? o What preconditions should exist before the story begins? o What main tasks / functions are performed by the actor? o What exceptions might come up as the story is described? o What variations in the actors interaction are possible? o What system info will the actor acquire, produce / change? o Will the actor have to inform the system about changes in the external environment? o What information does the actor desire from the system? o Does the actor wish to be informed of unexpected changes? Use-cases can be further elaborated to provide more detail Use-cases can be assessed by stakeholders, and assigned priority A use-case for making a withdrawal at an ATM:

Use case: ATM withdrawal Primary actor: Client Goal in context: To withdraw cash from the ATM quickly and securely Pre-conditions: The system has been programmed to recognize the insertion of the bank card and input of a password. Trigger: Bank card and password Scenario: 1. User inserts bank card 2. User keys in password 3. User selects which account to draw cash from 4. User keys in the amount of cash 5. User collects cash 6. ATM: Checks if another transaction is required 7. ATM: Ejects bank card if no further transactions are required 8. ATM: Prints bank slip Exceptions: 1. ATM out of order 2. Incorrect password entered 3. Password not recognized after 3 attempts 4. ATM does not eject bank card at the end of the transaction 5. User takes a long time to make a selection / to enter password Priority: Essential, must be implemented When available: First increment Frequency of use: As many times as required Channel to actor: Via ATM control panel Secondary actors: ATM machine, camera 23

Channels to secondary actors: ATM machine: computer networks. ATM machine is independent of the location. Camera installed for the safety of the client. Open issues: 1. Should the client use biometrics instead of PIN numbers? 2. Should the ATM machine display client additional information? 3. What will happen if there is a power failure during transaction? 4. How many cameras are to be installed to allow proper identification should a robbery occur?

Insert card Enter password

Select account ATM machine

Enter amount

Process transaction Dispense cash Eject card

Print slip

3. Elaboration: Building the analysis model The analysis model provides a description of the required informational, functional, and behavioral domains for a system The analysis model is a snapshot of requirements at a given time As the analysis model evolves, some elements become stable, while others may be more volatile, indicating that the customer doesnt yet fully understand requirements for the system Elements of the analysis model 24

Using different modes of representation forces you to consider requirements from different viewpoints, which is better Generic elements common to most analysis models: o Scenario-based elements Template-based use-cases Activity diagrams o Class-based elements Class diagrams o Behavioral elements State diagrams o Flow-oriented elements Data / control flow models Analysis patterns Definition of analysis patterns: o Things that reoccur across all projects within a specific application domain. They represent something that can be reused (e.g. a class, function, behavior) Two benefits that can be associated with analysis patterns: o They speed up the development of abstract analysis models o They facilitate the transformation of the analysis model into a design model by suggesting design patterns Information about an analysis pattern is presented in a template with these headings: Pattern name | Intent | Motivation | Forces and context | Solution | Consequences | Design | Known uses | Related patterns Why we say that the analysis model represents a snapshot of a system in time: o 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 software engineers learn more about the system to be built and as stakeholders understand more about what they really require. For that reason, the analysis model is a snapshot of requirements at any time.

4. Negotiating requirements Activities for the beginning of each software process iteration: 1. Identification of the system / subsystems 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 If youve convinced the customer to agree to every demand you have, does that make you a master negotiator? o There should be no winner or loser in a negotiating situation. Both sides should win. Best negotiations strive

25

for a win-win result, so if the customer feels he has won, that makes you a master negotiator.

6. Validating requirements Questions to ask when reviewing requirements: Is each requirement consistent with the overall objectives? Are all requirements specified at the right level of abstraction Is the requirement really necessary? Is each requirement bounded and unambiguous? Is a source (e.g. an individual) noted for each requirement? Do any requirements conflict with other requirements? Is each requirement achievable in the systems environment? Is each requirement testable, once implemented? Does the requirements model reflect the systems behavior? Has the requirements model been partitioned to progressively expose more detailed information about the system? Have requirements patterns been used to simplify the model? Have they all been validated? Are they consistent with requirements? Define customer for IS developers, builders of computer-based products, and system builders: o The customer for IS developers is often another department in the same company often the user department o The customer for builders of computer-based products is typically the marketing department o The customer for system builders may be an internal department, marketing, or an outside entity Why many developers dont pay enough attention to requirements engineering, and circumstances where you can skip it: o Software engineers want to begin building something, so they sometimes give requirement analysis short shrift. In addition, understanding the requirements of a problem is difficult, since requirements change, can be contradictory, and are often difficult to enunciate clearly. Hence, software engineers want to get through this activity quickly. o If the problem is relatively small and reasonably well understood, an abbreviated approach may be chosen. For more complex problems with many requirements, every task defined for comprehensive requirements engineering should be performed rigorously. Requirements engineering builds a bridge to design and construction and cannot be skipped.

26

Chapter 8 Building the analysis model

Requirements analysis Result: specification of softwares operational characteristics Indicates softwares interface with other system elements Establishes constraints that software must meet Allows the software engineer to elaborate on basic requirements established during earlier requirement engineering tasks Provides the software designer with a representation of info, function, and behavior to be translated into designs The analysis model & requirements specification provide the developer & customer with the means to assess quality Throughout analysis modeling, the main focus is on what, not how Overall objective and philosophy The analysis model must achieve 3 primary objectives: o Describe what the customer requires o Establish a basis for the creation of a software design o Define a set of requirements that can be validated later The analysis model bridges the gap between a system-level description and a software design Analysis rules of thumb The model should focus on requirements that are visible within the problem / business domain & have a high level of abstraction Each element of the analysis 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 Minimize coupling throughout the system Make sure the analysis model provides value to all stakeholders Keep the model as simple as it can be Domain analysis Analysis patterns often reoccur across many applications within a specific business domain If these patterns are defined and categorized to allow reuse, then creation of the analysis model is speeded up More important, the likelihood of applying reusable design patterns and executable software components grows dramatically Software domain analysis = the identification, analysis, and specification of common requirements from a specific application domain, for reuse on multiple projects within that domain 27

Goal of domain analysis: To find / create those analysis classes / common functions and features that are broadly applicable, so that they may be reused Role of the domain analyst: to discover and define reusable analysis patterns, analysis classes, and related info that may be used by many people working on similar applications Key inputs for domain analysis: o Technical literature o Existing applications o Customer surveys o Expert advice o Current / future requirements Key outputs for domain analysis: o Class taxonomies o Reuse standards o Functional models o Domain languages The purpose of domain analysis and how it is related to the concept of requirements patterns: o Domain analysis is an on-going SE activity that is not connected to any one software project. The intent is to find analysis patterns that are widely used within a specific application domain and to identify a set of objects and classes that characterize the domain. An analysis rule of thumb is that the model should focus on requirements that are visible within the problem or business domain. What types of requirements are not visible in these domains? Provide a few examples. o Many infrastructure requirements, e.g. Functions required to manage global data Functions required to implement network communication Functions required to implement a user interface

Analysis modeling approaches Describe the differences between structured and OO analysis Structured analysis o Data is separate from the processes that transform the data o Data objects are modeled to show attributes & relationships o Processes are modeled in a manner that shows how they transform data as data objects flow through the system: DFD Object-oriented analysis o Focuses on the definition of classes and the manner in which they collaborate with one another Elements of the analysis model: o Class-based elements Class diagrams 28

 Analysis packages CRC models Collaboration diagrams o Scenario-based elements Use-cases text Use-case diagrams Activity diagrams Swim lane diagrams o Flow-oriented elements Data flow diagrams Control-flow diagrams Processing narratives o Behavioral elements State diagrams Sequence diagrams Is it possible to develop an effective analysis model without developing all four of the above elements? o Yes, although each element presents a different view and provides the ability to see potential problems. In addition, if all four elements are developed, the transition to design is simplified. Is it possible to begin coding immediately after an analysis model has been created? o The analysis model will serve as the basis for design and construction of the domain objects. It is possible to begin coding after the objects and attributes are defined and relationships are known. However, the design will suffer as a result because explicit architectural design will not have been considered; interfaces will have been developed in a haphazard manner and global data structures will not have been explicitly designed.

Data modeling concepts Analysis modeling often begins with data modeling The analyst defines: all data objects that are processed within the system, the relationships between the data objects, and other info that is pertinent to the relationships Data objects = a representation of composite information E.g. dimensions, which incorporates height, width, and depth A data object can be a thing (report), occurrence (phone call), event (alarm), role (salesperson), organizational unit (sales dept), place (warehouse), or a structure (file) The data object description incorporates the data object and all of its attributes there is no reference to operations 29

Data attributes They define properties of a data object and can be used to: o Name an instance of the data object o Describe the instance o Make reference to another instance in another table One or more of the attributes must be defined as an ID (key) Relationships Indicate how data objects are connected to one another Cardinality and modality Cardinality = the no of occurrences of objects in a relationship Modality = 0 if there is no explicit need for the relationship Modality = 1 if an occurrence of the relationship is mandatory Object-oriented analysis Tasks for OO: 1. Basic user requirements must be communicated between customer & software engineer 2. Classes must be identified (with attributes & methods) 3. A class hierarchy is defined 4. Define object-to-object relationships (connections) 5. Object behavior must be modeled 6. 1 5 are reapplied iteratively until the model is complete Scenario-based modeling Writing use-cases Inception & elicitation provide the info needed to begin Requirements gathering mechanisms are used to o Identify stakeholders o Define the scope of the problem o Specify overall operational goals o Outline all known functional requirements o Describe the objects that will be manipulated by the system Begin by listing functions / activities of a specific actor Primary scenarios dont consider any alternative interactions Secondary scenarios answer these questions: o Can the actor take some other action? o What error conditions could occur? o Might the actor encounter some other (external) behavior? Developing an activity diagram Supplements the use case with a graphical representation of the flow of interaction within a specific scenario (flow chart!) The activity diagram adds additional detail not directly mentioned (but implied) by the use case Rounded rectangles imply a specific function Arrows represent flow through the system Decision diamonds depict a branching decision 30

 Solid horizontal lines indicate parallel activities Swimlane diagrams A variation of the activity diagram Additional info: indicates which actor / class is responsible for the action described by an activity rectangle Responsibilities are represented as parallel segments that divide the diagram vertically Flow-oriented modeling The DFD can be used to complement UML diagrams The DFD takes an input-process-output view of a system The DFD is presented in a hierarchical fashion, with the first data flow model (level 0 DFD) representing the system as a whole Creating a data flow model The DFD enables you to develop models of the information domain and functional domain at the same time Performing a grammatical parse on the processing narrative can generate useful info about how to proceed As the DFD is refined into greater levels of detail, the analyst performs an implicit functional decomposition of the system Refine the DFDs until each bubble is single-minded Creating a control flow model Needed (in addition to the DFD) for applications that: o are driven by events rather than data o produce control information rather than reports / displays o process info with heavy concern for time & performance An event / control item is implemented as a Boolean value / discrete list of conditions (empty/full) The control specification (CSPEC) Represents the behavior of the system in 2 different ways: State diagram o A sequential specification of behavior Program activation table o A combinatorial specification of behavior The CSPEC describes behavior, but not the inner workings of the processes that are activated as a result of this behavior The process specification (PSPEC) Used to describe all flow model processes that appear at the final level of refinement The content can include: o Narrative text o Program design language (PDL) description of the algorithm o Mathematical equations, tables, diagrams, charts By providing a PSPEC to accompany each bubble in the flow model, you crate a mini-spec that can serve as a guide for design of the software component that will implement the process 31

Class-based modeling Identifying analysis classes Examine the problem statement and perform a grammatical parse on the use-cases or processing narratives developed for the system 6 selection characteristics when considering potential classes: 1. Retained information o Must class info be remembered for the system to function? 2. Needed services o Are there operations that can change the attribute values? 3. Multiple attributes o A 1-attribute class should be an attribute of another class 4. Common attributes o Can attributes be applied to all instances of the class? 5. Common operations o Can operations be applied to all instances of the class? 6. Essential requirements o External entities that produce / consume info essential to the systems operation will always be defined as classes A potential class should satisfy all the above characteristics Specifying attributes Study a use-case and select things that belong to the class Ask: What data items define this class in the problem context? Defining operations 1. Operations that manipulate data (E.g. add, delete, select) 2. Operations that perform a computation 3. Operations that inquire about the objects state 4. Operations that monitor an object for the occurrence of an event The grammatical parse is again studied and verbs are isolated CRC modeling Class: FloorPlan (Description) Responsibility: Defines floor plan name/type Incorporates walls, doors and windows Shows position of video cameras

Collaborator: Wall Camera

Classes Entity classes (model / business classes) o Come directly from the problem statement (e.g. FloorPlan) o Typically represent things to be stored in a database o Persist throughout the duration of the application Boundary classes o Used to create the interface (e.g. interactive screen) o Manage the way entity objects are presented to the user Controller classes o Manage a unit of work from start to finish: The creation / update of entity objects 32

 The instantiation of boundary objects Complex communication between sets of objects Validation of data communicated between objects o Generally not considered until design has begun Responsibilities (attributes & operations) Guidelines for allocating responsibilities: 1. System intelligence should be distributed across classes o If dumb classes are servants to smart classes It concentrates all intelligence within a few classes, making changes more difficult It tends to require more classes, i.e. more effort o If a class has a very long list of responsibilities, this is an indication of a concentration of intelligence o In addition, the responsibilities should exhibit the same level of abstraction 2. Each responsibility should be stated as generally as possible o So that they can apply to all subclasses 3. Information & related behavior should reside in the same class o This achieves encapsulation a cohesive unit 4. Information about one thing should be localized with a single class, not distributed across multiple classes 5. Share responsibilities among related classes, when appropriate o E.g. arms and legs collaborate with each other Collaborators Collaborations identify relationships between classes First see whether a class can fulfill each responsibility itself There are three different generic relationships between classes: o Is-part-of relationship Classes that are part of an aggregate class o Has-knowledge-of relationship When one class must acquire info from another class o Depends-upon relationship Other dependencies, e.g. head connected to body When a complete CRC model has been developed it can be reviewed: 1. All participants in the review are given a subset of the cards 2. All use-case scenarios should be organized into categories 3. The review leader reads the use-case deliberately. As he comes to a named class, he passes a token to the person holding the corresponding class index card. 4. When the token is passed, the holder of the class card must describe the responsibilities noted on the card 5. If the responsibilities and collaborations cannot accommodate the use-case, modifications are made to the cards Associations and dependencies The difference between associations and dependencies: An association defines a relationship between classes A dependency relationship exists with clients & servers Dependencies are defined by a stereotype 33

Stereotype = a UML extensibility mechanism that allows you to define a special modeling element with custom-defined semantics In UML stereotypes are represented in <<double angle brackets>> Analysis packages What is an analysis package and how might it be used? o A package is used to assemble a collection of related classes and other elements of the analysis model Creating a behavioral model The behavioral model indicates how software will respond to external events or stimuli To create the model, the analyst must perform these steps: o Evaluate all use-cases to fully understand the sequence of interaction within the system o Identify events that drive the interaction sequence and understand how these events relate to specific classes o Create a sequence for each use-case o Build a state diagram for the system o Review the behavioral model to check accuracy & consistency Identifying events with the use case An event occurs whenever the system & actor exchange information Note the info exchanged, and list any conditions / constraints After identifying all events, allocate them to objects: o Objects can generate events o Objects can recognize events State representations Two different characterizations of states must be considered: o The state of each class as the system performs its function o The state of the system as observed from the outside as the system performs its function The state of a class takes on passive & active characteristics: o Passive state = current status of an objects attributes o Active state = current status of the object as it undergoes a continuing transformation / processing 1. State diagrams for analysis classes o Shows how a class changes state based on external events o In addition to specifying the event that causes the transition to occur, you can specify a guard and an action o Guard = a Boolean condition that must be satisfied in order for the transition to occur o Action = something that occurs concurrently with the state transition or as a consequence of it 2. Sequence diagrams o Shows the behavior of the software as a function of time o Shows how events cause transitions from object to object o After developing a complete sequence diagram, all of the events that cause transitions between system objects can be collated into a set of input events and output events 34

How a state diagram for analysis classes differs from the state diagrams presented for the complete system: o The state diagrams depicting the state behavior of a system represent externally observable events and states. o State diagrams for analysis classes are a component of the behavioral model and represent the states associated with a specific analysis class.

Chapter 9 Design engineering

Design within the context of software engineering Each element of the analysis model provides information necessary to create the 4 design models required: Data/class design o Transforms analysis-class models into design class realizations and data structures Architectural design o Defines the relationship between major structural elements of the software, the architectural styles and design patterns that can be used to achieve the requirements Interface design o Describes how the software communicates with systems that interoperate with it, and with humans who use it Component-level design o Transforms structural elements of the software architecture into a procedural description of software components If a software design is not a program, then what is it? o The intent of software design is to apply a set of principles, concepts, and practices that lead to the development of a high quality system. The goal of design is to create a model of software that will implement all customer requirements correctly and bring delight to users. Do you design software when you write a program? What makes software design different from coding? o Yes, but the design is conducted implicitly often in a haphazard manner. During design (in a software engineering context) we develop representations (models) of programs not the programs themselves.

Design process and design quality Three characteristics that serve as a guide for the evaluation of good design: o The design must implement all of the explicit requirements contained in the analysis model, and must accommodate all of the implicit requirements desired by the customer 35

o The design must be a readable, understandable guide for those who generate code and for those who test the software o The design should provide a complete picture of the software, addressing the data, functional, and behavioral domains from an implementation perspective Quality guidelines o A design should exhibit an architecture that Has been created using architectural styles / patterns Has components with good design characteristics Can be implemented in an evolutionary fashion o A design should be modular o A design should contain distinct representations of data, architecture, interfaces, and components o Data structures should be appropriate for the classes o Components should be functionally independent o Interfaces should reduce complexity of connections between components and with the external environment o Design using a repeatable method that is driven by information obtained during requirements analysis o Use a notation that effectively communicates its meaning Quality attributes o Functionality o Usability o Reliability o Performance o Supportability How we assess the quality of a software design: o Quality is assessed by conducting a series of FTRs and then assessing the design against a set of quality criteria o Members of the FTR meeting: Review leader (sets an agenda) Recorder (takes notes) Producer (has his work reviewed)

Design concepts Abstraction At the highest level of abstraction, a solution is stated in broad terms using the language of the problem environment At lower levels of abstraction more details are provided Procedural abstraction o Instructions that have a specific and limited function o E.g. Open implies a long sequence of procedural steps Data abstraction o A named collection of data that describes a data object o E.g. Door encompasses attributes like type, dimension Architecture Describe software architecture in your own words: 36

o The overall structure of the program components, how they interact, and the structure of the data that they use. Architecture is also about the ways in which that structure provides conceptual integrity for a system. The architecture serves as a framework from which more detailed design activities are conducted The architectural design can be represented using these models: o Structural models Represent architecture as a collection of components o Framework models Identify repeatable architectural design frameworks that are encountered in similar types of applications o Dynamic models Address the behavioral aspects of the architecture, indicating how events can change the structure o Process models Focus on the design of the business or technical process that the system must accommodate o Functional models Represent the functional hierarchy of a system Patterns Describe design structures that solve particular design problems within specific contexts The intent of each design pattern is to provide a description that enables a designer to determine o Whether the pattern is applicable to the current work o Whether the pattern can be reused o Whether the pattern can serve as a guide for developing a similar, but functionally or structurally different pattern Modularity The effort to develop an individual software module does decrease as the total number of modules increases However, as the number of modules grows, the effort associated with integrating the modules also grows Reasons for modularizing a design: o Development can be more easily planned o Software increments can be defined & delivered o Changes can be more easily accommodated o Testing & debugging can be conducted more efficiently o Long-term maintenance wont have serious side effects Information hiding Details of data structures are hidden behind a module interface Modules communicate with each other only the info necessary to achieve a software function Benefit: inadvertent errors introduced during modification are less likely to propagate to other locations within the software Functional independence Modules have few functions & interactions with other modules 37

This makes them easier to maintain and test because error propagation is reduced, and reuse is possible Independence is assessed using two qualitative criteria: o Cohesion Indication of a modules relative functional strength o Coupling Indication of the interdependence among modules Refinement You develop a hierarchy by decomposing macroscopic functions until reaching programming language statements Refinement is actually a process of elaboration because you provide more and more detail with each successive refinement Abstraction and refinement are complementary concepts: o Abstraction enables a designer to specify procedure and data and yet suppress low-level details o Stepwise Refinement helps the designer to reveal low-level details as design progresses Refactoring Refactoring is a reorganization technique that simplifies the design of a component without changing its function / behavior When software is refactored, the existing design is examined for redundancy, unused design elements, inefficient algorithms, etc. Design classes Analysis classes represent objects, while design classes present more technical detail as a guide for implementation The design classes must o Refine the analysis classes by providing design detail that will enable the classes to be implemented o Include new classes to implement a software infrastructure Five different types of design classes: o User interface classes (E.g. elements of a metaphor) o Business domain classes (refinements of analysis classes) o Process classes (implement low-level business abstractions) o Persistent classes (represent data stores) o System classes (functions that enable the system to operate & communicate within its computing environment & the world) Four characteristics of a well-formed design class: o Complete and sufficient (encapsulate all methods necessary and nothing more) o Primitiveness (methods should accomplish one service) o High cohesion o Low coupling The design model Two dimensions of the design model: o Process dimension Indicates the evolution of the design model as design tasks are executed as part of the software process 38

o Abstraction dimension Represents the level of detail as each element of the analysis model is transformed into a design equivalent The elements of the design model use many of the same UML diagrams that were used in the analysis model, but o These diagrams are refined and elaborated o More implementation-specific detail is provided o Architectural structure and style are emphasized o Interfaces between components are emphasized

Data design elements Data design creates a model of data that is represented at a high level of abstraction (the users view of data) It is then refined into progressively more implementationspecific representations that can be processed by the system At the program component level o Design of data structures & associated algorithms At the application level o Translation of a data model into a database At the business level o Data reorganized into a data warehouse enables data mining Architectural design elements The architectural model is derived from three sources: o Information about the application domain o Specific analysis model elements, like DFDs, their relationships and collaborations for the problem o The availability of architectural patterns and styles Interface design elements These elements tell how information flows into and out of the system and how it is communicated among the components Three important elements of interface design: o The user interface o External interfaces to other systems Collect this info during requirements engineering Incorporate error checking and security features o Internal interfaces between various design components Design realizations of analysis classes show messaging Each message must be able to perform the info transfer Component-level design elements Component-level design fully describes the internal detail of each software component Component-level design defines o Data structures for all local data objects o Algorithmic detail for all processing o An interface that allows access to all component operations The design details of a component can be modeled at many different levels of abstraction: 39

o Activity diagram to represent processing logic o Pseudo code to represent detailed procedural flow Deployment-level design elements Indicate how software functionality and subsystems will be allocated within the physical computing environment Deployment diagrams show computing elements, with subsystems o Descriptor form No explicit indication of configuration details o Instance form Later stages of design with details Pattern-based software design Describing a design pattern Design pattern template: Pattern name Describes the essence of the pattern Intent What the pattern does

The classes to implement the pattern Participants The responsibilities of the classes Also known as Synonyms Collaborations How the participants collaborate Motivation An example of the Consequences Trade-offs to problem consider Applicability Specific design Related patterns Cross-references situations where related design it is applicable patterns A description of the design pattern may also consider a set of design forces, that describe nonfunctional requirements Forces define the constraints that restrict the implementation Pattern characteristics indicate the design attributes that may be adjusted to allow the pattern to accommodate various problems Guidance associated with the use of a design pattern provides an indication of the ramifications of design decisions Using patterns in design Architectural patterns o Define the overall structure of the software o Indicate relationships among subsystems & components Design patterns o Address a specific element of the design o E.g. an aggregation of components to solve a problem, relationships among components, communication mechanisms Idioms (coding patterns) o Implement an algorithmic element of a component, a specific interface protocol, or a communication mechanism Each of these pattern types differs in the o Level of abstraction with which it is represented 40

Structure

o Degree to which it provides guidance for construction Frameworks Definition: an implementation-specific skeletal infrastructure The skeleton has a collection of plug points that enable it to be adapted to a specific problem domain The plug points enable a designer to integrate problem specific classes or functionality within the skeleton OO context: a framework is a collection of cooperating classes To be most effective, frameworks are applied with no changes Additional design elements may be added, but only via the plug points that allow the designer to flesh out the skeleton

Chapter 10 Creating an architectural design

Software architecture What is architecture? Definition: The structure of the system, which comprises: o Software components, o the externally visible properties of those components o and the relationships among them Architecture is a representation that lets a software engineer: o Analyze the effectiveness of the design in meeting its stated requirements o Consider architectural alternatives at a stage when making design changes is still relatively easy o Reduce the risks associated with constructing software The definition emphasizes the role of software components in any architectural representation A software component can be a program module / OO class / databases / middleware Architecture design considers two levels of the design pyramid: o Data design Class definitions in OO systems o Architectural design Focuses on the representation of the structure of software components, their properties, & interactions Why is architecture important? 1. Enables communication between all stakeholders 2. Highlights early design decisions that will have a profound impact on all SE work that follows 3. Constitutes a relatively small, graspable model of how the system is structured and how its components work together Data design Data design translates data objects defined as part of the analysis model into data structures at the software component level and a database architecture at the application level Data design at the architectural level 41

Data mining techniques / KDB (knowledge discovery in databases) navigate through existing databases to extract appropriate info Data mining is difficult in an existing database environment, so a data warehouse adds an additional layer to the architecture Data warehouse = a separate data environment not directly integrated with day-to-day applications that encompasses all data used by a business Data design at the component level Focuses on the representation of data structures that are directly accessed by one or more software components Principles applicable to data design: o The systematic analysis principles applied to function & behavior should also be applied to data o All data structures and the operations to be performed on each should be identified o Establish a mechanism for defining the content of each data object and the data & operations applied to it o Leave low-level data design decisions for later o Only the modules that use the data directly should know the representation of the data structure o A library of useful data structures and the operations that may be applied to them should be developed o A software design and programming language should support the specification and realization of abstract data types Architectural styles and patterns Architectural styles describe a system category encompassing: o A set of components (e.g. database, computational modules) o A set of connectors that enable communication, coordination, and cooperation among components o Constraints for how components can be integrated to form the system o Semantic models that let a designer understand the overall system properties by analyzing the properties of its parts An architectural style is a transformation imposed on the design of an entire system & establishes a structure for all components An architectural pattern also imposes a transformation on the design of an architecture, but it differs from a style: o The scope is less broad, focusing on one aspect of the architecture rather than the architecture in its entirety o A pattern imposes a rule on the architecture, describing how the software will handle an aspect of its functionality o Architectural patterns tend to address specific behavioral issues within the context of the architecture Taxonomy of architectural styles Data-centered architecture o A data store resides at the centre of this architecture and is accessed frequently by other components that modify it 42

o Integrability: components can be changed & new ones added to the architecture without concern about other clients o Client components independently execute processes Data-flow architectures o When input data are to be transformed into output data o Pipe & filter structure: filters are connected by pipes that transmit data from one component to the next o If the data flow degenerates into a single line of transforms, it is termed batch sequential Call and return architecture o Program structure that is easy to modify & scale Main program/subprogram architecture Control hierarchy: a main program invokes program components, which in turn may invoke still others Remote procedure call architecture The components of a main program / subprogram architecture are distributed on a network OO architecture o The components of a system encapsulate data and the operations that must be applied to manipulate the data o Message passing to accomplish communication & coordination Layered architecture o Different layers, each accomplishing operations that progressively become closer to the machine instruction set Outer layer: components service UI operations Intermediate layers: provide utility services and application software functions Inner layer: components perform OS interfacing Architectural patterns Concurrency o Many applications must handle multiple tasks in a manner that simulates parallelism o Ways to handle concurrency: Use an OS process management pattern that provides built-in OS features that allow concurrent execution Define a task scheduler at the application level Persistence o A DBMS pattern applies storage & retrieval capability o An application level persistence pattern builds persistence features into the application architecture Distribution o Addresses the manner in which systems / components communicate with one another in a distributed environment o There are two elements to this problem: The way in which entities connect to one another The nature of the communication that occurs

43

o A common architectural pattern established to address the distribution problem is the broker pattern (E.g. CORBA) Organization and refinement Control o How is control managed within the architecture? o Does a distinct control hierarchy exist? o What is the role of components within the control hierarchy? o How do components transfer control within the system? o How is control shared among components? o What is the control topology? o Is control synchronized / asynchronous? Data o How are data communicated between components? o Is the flow of data continuous/ sporadic? o What is the mode of data transfer? o Do data components exist and what is their role? o How do functional components interact with data components? o Are data components passive / active? o How do data and control interact within the system?

Chapter 13 Testing strategies

A strategic approach to software testing A template for software testing should be defined Characteristics of testing strategies: o A software team should conduct effective formal technical reviews to eliminate errors before testing commences o Testing begins at the component level and works outward towards the integration of the entire system o Different testing techniques are appropriate at different points in time o Testing is conducted by the developer of the software and (for large projects) an independent test group o Testing and debugging are different activities, but debugging must be accommodated in any testing strategy Low-level tests verify small source code segments High-level tests validate major system functions Verification and validation The difference between verification and validation: Verification = ensures that software correctly implements a specific function (Are we building the product right?) Validation = ensures that the software is traceable to customer requirements (Are we building the right product?) V&V encompasses a wide array of SQA activities including: formal technical reviews, performance monitoring, simulation, feasibility study, documentation review, algorithm analysis, development testing, usability testing, installation testing Organizing for software testing 44

The developer must test the individual units of the program The developer also conducts integration testing An independent test group becomes involved only after the software architecture is complete An ITG removes the conflict of interest that may be present The developer and ITG work closely throughout the project so that the developer can correct errors that are uncovered The ITG is part of the software development project team in the sense that it becomes involved during analysis & design and stays involved throughout a large project Some problems that might be associated with the creation of an independent test group. (Are an ITG and an SQA group made up of the same people?) o The most common problem in the creation of an ITG is getting and keeping good people o Hostility between the ITG and the SE group can arise o The ITG may get involved in a project too late, when a thorough job of test planning & execution cant be done o An ITG and an SQA group are not necessarily the same The ITG focuses solely on testing The SQA group considers all aspects of QA

A software testing strategy for conventional software architectures A software testing strategy may be viewed as a spiral: o Unit testing (Code) Concentrates on each unit o Integration testing (Design) Focuses on design & construction of the architecture o Validation testing (Requirements) Requirements are validated against the software o System testing (System engineering) The system and other elements are tested as a whole Why is it not always possible to develop a strategy for testing software that uses the above sequence of steps? What possible complications might arise for embedded systems? o The complexity of a test environment for unit testing (i.e. complicated drivers & stubs) may not justify the benefit o Integration testing is complicated by the scheduled availability of unit-tested modules (especially when such modules fall behind schedule) o For embedded systems, validation testing cannot be adequately conducted outside of the target hardware configuration, so validation & system testing are combined

A software testing strategy for OO architectures 45

Testing in the small testing in the large Instead of units, classes are tested As classes are integrated into an OO architecture, a series of regression tests are run to uncover errors due to o Communication & collaboration between classes o Side effects caused by the addition of new classes Finally, the system as a whole is tested Criteria for completion of testing Use statistical modeling and software reliability theory to get models of software failures as a function of execution time By collecting metrics during software testing and making use of existing software reliability models, it is possible to develop meaningful guidelines for knowing when testing can stop Strategic issues Guidelines that lead to a successful testing strategy: o Specify product requirements long before testing commences o State testing objectives explicitly o Understand the users and give a profile for each category o A testing plan should emphasize rapid cycle testing o Build robust software that is designed to test itself o Use formal technical reviews as a filter beforehand o Conduct FTRs to assess the test strategy and test cases o Develop a continuous improvement approach for testing Test strategies for conventional software Unit testing Tests important control paths and focuses on the internal processing logic and data structures within a component Can be conducted in parallel for multiple components Unit test considerations: Tests that occur as part of unit tests: o The module interface is tested to ensure that information properly flows into & out of the program unit under test o Local data structures are examined to ensure that data stored temporarily maintains its integrity o All independent paths are exercised to ensure that all statements in a module have been executed at least once o Boundary conditions are tested o All error handling paths are tested Some common errors found during unit testing: o Misunderstood / incorrect arithmetic precedence o Mixed mode operations o Incorrect initialization o Precision inaccuracy o Incorrect symbolic representation of an expression Test cases should uncover errors such as: o Comparison of different data types 46

o Incorrect logical operators / precedence o Expectation of equality with precision errors o Incorrect comparison of variables o Improper / nonexistent loop termination o Failure to exit when divergent iteration is encountered o Improperly modified loop variables Boundary testing is one of the most important unit test tasks Potential errors to be tested when error handling is evaluated: o Error description is unintelligible o Error noted does not correspond to error encountered o Error causes OS intervention prior to error handling o Exception-condition processing is incorrect o Error description doesnt provide enough info to assist Unit test procedures: Unit testing is normally considered as an adjunct to coding The design of unit tests can be performed before coding begins or after source code has been generated Each test case should be coupled with a set of expected results Because a component is not a stand-alone program, driver and/or stub software must be developed for each unit test o A driver is a main program that accepts test case data o Stubs serve to replace modules subordinate to the component Unit testing is simplified when a component has high cohesion Why a highly coupled module is difficult to unit test: o A highly coupled module interacts with other modules, data and other system elements, so its function is often dependent on the operation of these coupled elements o In order to unit-test such a module thoroughly, the function of the coupled elements must be simulated in some manner, which can be difficult and time-consuming Is unit testing possible or even desirable in all circumstances? o No, if a module has 3 or 4 subordinates that supply data essential to a meaningful evaluation of the module, it may not be possible to conduct a unit test without clustering all of the modules as a unit

Integration testing Problems that can occur when you integrate modules together: o Data can be lost across an interface o One module can have adverse affects on others o Individually acceptable imprecision may be magnified Integration testing uncovers errors associated with interfacing The program is constructed and tested in small increments, where errors are easier to isolate and correct 1. Top-down integration Work from the main program down through the control hierarchy 47

Modules subordinate to the main control module are incorporated into the structure in either a depth-first or breadth-first way: o Depth-first integration Integrates all components on a major control path A complete function may be implemented & demonstrated o Breadth-first integration Incorporates all components at the same level Steps for the integration process: 1) The main control module is used as a test driver, and stubs are substituted for all components directly underneath 2) Stubs are replaced one at a time with actual components 3) Tests are conducted as each component is integrated 4) On completion of each set of tests, another stub is replaced with the real component 5) Regression testing may be conducted to ensure that new errors have not been introduced Verifies major control / decision points early in testing In a well-factored program structure, decision making occurs at upper levels in the hierarchy and is therefore encountered first Problems encountered with top-down testing: o When processing at low levels in the hierarchy is required to adequately test upper levels, you have 3 choices: Delay many tests until stubs are replaced with modules Difficult to determine the cause of errors Develop stubs that simulate the actual module Can lead to overhead as stubs become more complex Do a bottom-up integration 2. Bottom-up integration Begins with atomic modules at the lowest levels in the program No stubs because subordinate components are always available Implementation steps: 1) Low-level components are combined into clusters that perform a specific software sub-function 2) A driver is written to coordinate test case input & output 3) The cluster is tested 4) Drivers are removed and clusters are combined moving upward in the program structure 3. Regression testing When a new module is integrated, there are changes which may cause problems with functions that previously worked Regression testing = the re-execution of some subset of tests that have already been conducted to ensure that changes have not propagated unintended side effects Regression testing may be conducted o Manually By re-executing a subset of all test cases o Automatically 48

With capture/playback tools that let you capture test cases & results for subsequent playback & comparison The regression test suite has 3 different classes of test cases: o Tests that will exercise all software functions o Additional tests that focus on software functions that are likely to be affected by the change o Tests that focus on the changed software components Because the number of regression tests can grow quite large, they should only address a few errors in each major function 4. Smoke testing Designed as a pacing mechanism for time-critical projects, allowing the team to assess its project on a frequent basis Encompasses these activities: 1) Software components that have been translated into code are integrated into a build (includes data files, libraries) 2) A series of tests is designed to expose errors that will keep the build from properly performing its function 3) The build is integrated with other builds and the entire product is smoke tested daily Benefits: o Integration risk is minimized o The quality of the end-product is improved o Error diagnosis and correction are simplified o Progress is easier to assess Strategic options Disadvantage of top-down approach: the need for stubs Disadvantage of bottom-up approach: the program as an entity doesnt exist until the last module is added Sandwich testing = a combined approach that uses top-down tests for upper levels, and bottom-up tests for subordinate levels During integration testing, you should identify critical modules Characteristics of a critical module: o Addresses several software requirements o Has a high level of control (i.e. high in the structure) o Is complex / error prone o Has definite performance requirements Critical modules should be tested as early as possible Regression tests should focus on critical module functions Integration test documentation An overall plan for software integration and a description of specific tests are documented in a test specification This document contains a o Test plan (with an integration strategy) o Test procedure (with testing details) Testing is divided into phases and builds that address specific functional and behavioral characteristics of the software Criteria applied for all test phases: o Interface integrity 49

 Test Unit

o Functional validity o Information content o Performance The history of actual test results, problems, or peculiarities is recorded in a test report, added to the test specification

strategies for OO software testing in the OO context An encapsulated class is usually the focus of unit testing Operations within the class are the smallest testable units We can no longer test a single operation in isolation, but rather as part of a class Integration testing in the OO context Thread-based testing o Integrates the set of classes required to respond to one input / event for the system o Each thread is integrated and tested individually o Regression testing, to ensure that no side effects occur Use-based testing o First test those classes (independent classes) that use very few server classes o Then test the next layer of classes (dependent classes) which use the independent classes The use of drivers & stubs also changes with OO testing Drivers can be used to test operations at the lowest level and for the testing of whole groups of classes A driver can also be used to replace the user interface so that you can test the system functionality before having an interface Stubs can be used when collaboration between classes is required but one or more of those classes has not yet been implemented Cluster testing is a step in integration testing of OO software: o A cluster of collaborating classes (from CRC) is tested to try uncover errors in the collaborations Validation testing The software requirements specification is a document that describes all user-visible attributes of the software The specification contains a section called validation criteria with info that forms the basis for a validation testing approach Validation test criteria A test plan outlines the classes of tests to be conducted A test procedure defines specific test cases Both plan & procedure are designed to ensure that o All functional requirements are satisfied o All behavioral characteristics are achieved o All performance requirements are attained o Documentation is correct o Usability and other requirements are met (compatibility) 50

After each validation test one of two possible conditions exist: o The function / performance characteristic is accepted o A deviation from specification is uncovered and a deficiency list is created Configuration review (audit) Purpose: ensures that all elements of the software configuration o Have been properly developed o Are cataloged o Have the necessary detail to bolster the support phase Alpha and beta testing Alpha testing o Conducted at the developers site by end-users o The software is used in a natural setting and the developer looks over the shoulder of users and records problems o Conducted in a controlled environment Beta testing o Conducted at end-user sites o The developer is generally not present o The test is a live application of the software in an environment that cant be controlled by the developer o The end-user records all problems and reports them Who should perform the validation test the software developer or the software user, and why? o The software user, because you want the user to say that the software performs to their expectations

System testing System testing = a series of different tests that verify element integration and functionality Recovery testing Recovery testing forces the software to fail in a variety of ways and verifies that recovery is properly performed Automatic recovery: evaluate re-initialization, checkpointing mechanisms, data recovery, and restart for correctness Manual recovery: evaluate mean-time-to-repair (MTTR) Security testing Verifies the protection mechanisms built into the system The tester plays the role of the hacker / spy Stress testing Executes a system with abnormal quantity, frequency, or volume Sensitivity testing: Sometimes a very small range of data may cause extreme processing / performance degradation Sensitivity testing uncovers data combinations with valid input classes that may cause instability / improper processing Performance testing Tests the run-time performance 51

Occurs throughout all steps in the testing process, but shows true system performance only when all elements are integrated Often coupled with stress testing and usually requires both hardware & software instrumentation (i.e. measuring resource utilization, like processor cycles) External instrumentation can monitor execution intervals, log events, and sample machine states on a regular basis By instrumenting a system, the tester can uncover situations that lead to degradation and possible system failure

The art of debugging Debugging occurs as a consequence of successful testing When a test case uncovers an error, debugging removes it The debugging process Debugging begins with the execution of a test case Results are assessed and a lack of correspondence between expected & actual performance is encountered Debugging will always have one of two outcomes: o The cause will be found and corrected o The cause will not be found Why debugging is so difficult: o The symptom and the cause may be geographically remote o The symptom may disappear when another error is corrected o The symptom may actually be caused by non-errors o The symptom may be caused by non-traceable human error o The symptom may be a result of timing problems o It may be difficult to reproduce input conditions o The symptom may be intermittent o The symptom may be due to causes that are distributed across a number of tasks running on different processors Debugging strategies Debugging tactics Brute force o The most common and least efficient method o We apply brute force debugging methods when all else fails Backtracking o Manually trace backwards from the source o As the number of source lines increases, the number of potential backward paths may become unmanageably large Cause elimination o Manifested by induction / deduction and introduces the concept of binary partitioning o Data related to the error occurrence are organized to isolate potential causes o A cause hypothesis is devised, and the data are used to prove / disprove the hypothesis o Alternatively, a list of all possible causes is developed, and tests are conducted to eliminate each 52

Automated debugging IDEs provide a way to capture some of the language-specific errors without requiring recompilation Correcting the error Questions to ask before making a correction: o Is the cause of the bug reproduced elsewhere in the code? o Will the proposed fix introduce another bug? o How could we have prevented this bug in the first place?

Chapter 14 Testing tactics

Software testing fundamentals A software engineer should design and implement a system with testability in mind The tests must exhibit a set of characteristics that achieve the goal of finding the most errors with a minimum of effort Definition of testability: How easily a program can be tested Characteristics that lead to testable software: Operability o The better it works, the more efficiently it can be tested Observability o Inputs provided as part of testing produce distinct outputs Controllability o The better we can control the software, the more the testing can be automated and optimized Decomposability o The system is built from independent modules that can be tested independently Simplicity o Functional simplicity (Minimum feature set) o Structural simplicity (Modularized architecture) o Code simplicity (Coding standard for ease of inspection) Stability o The fewer the changes, the fewer the disruptions to testing Understandability o Well organized, specific & accurate technical documentation Test characteristics: A good test has a high probability of finding an error o Understand the software and picture how it might fail A good test is not redundant o Every test should have a different purpose 53

A good test should be best of breed o If you only have time to use a subset of tests, the test that has the highest likelihood of uncovering a whole class of errors should be used A good test should be neither too simple nor too complex o Although it is sometimes possible to combine a series of tests into one test case, rather execute them separately

Black-box testing Tests that are conducted at the software interface You know the function that the product must perform White-box (Glass-box) testing Close examination of procedural detail You know the internal workings of the product A limited number of important logical paths should be selected The software engineer can derive test cases that: o Guarantee that all independent paths within a module have been exercised at least once o Exercise all logical decisions on their true and false sides o Execute all loops at their boundaries and within their operational bounds o Exercise internal data structures to ensure their validity

Chapter 16 Web engineering

Attributes of Web-based systems and applications Network intensiveness o A WebApp must serve needs of a diverse community of clients Concurrency o A large number of users may access the WebApp at once Unpredictable load o The number of users may vary from day to day Performance o WebApp users dont want to wait too long for access Availability o Users often demand constant availability Data driven o The primary function of many WebApps is to use hypermedia to present text, graphics, audio, and video to end users Content sensitive o The quality and aesthetic nature of content remains NB Continuous evolution o WebApps evolve continuously, unlike conventional software Immediacy o Time schedules for WebApps are more compressed Security 54

o It is difficult to limit the users who access the WebApp Aesthetics o Part of the appeal of a WebApp is its look and feel Other generic attributes that differentiate WebApps from more conventional software applications: o Customizable Each user can customize the info to his own needs o Dependent The content may be dependent on the content of other WebApps (e.g. hot links to other websites) that are not under control of the WebApp developer o Responsive Users can comment on the WebApp in real-time and expect a timely response to their query / comments Application categories most commonly encounterd in WebE work: o Informational (Read-only content) o Download o Customizable (Communication among users) o Interaction o User input o Transaction-oriented o Service-oriented o Portal (Channels to other Web content) o Database access o Data warehousing

WebApp engineering layers Process WebE process models embrace the agile development philosophy Framework activities must be defined within a process that o Embraces change o Encourages the creativity & independence of staff o Builds systems using small development teams o Emphasizes evolutionary / incremental development Methods Communication methods o Important during requirements gathering & evaluation Requirements analysis methods o Provide a basis for understanding the content to deliver, the function to provide, and the modes of interaction Design methods o Address WebApp content, architecture, interface design, and navigation structure Testing methods o Incorporate formal technical reviews of content & design model and a wide array of testing techniques that address component-level and architectural issues, etc 55

Tools and technology Technologies encompass: HTML, VRML, XML, Java, CORBA, browsers, multimedia tools, site authoring tools, security tools The Web engineering process Because WebApps are often content-driven with an emphasis on aesthetics, it is likely that parallel development activities will be scheduled within the WebE process and involve a team of both technical and non-technical people Defining the framework Any of the agile process models can be applied as a WebE process Before we define a process framework for WebE, recognize that: o WebApps are often delivered incrementally o Changes will occur frequently o Timelines are short The WebE process within the generic process framework: o Customer communication Business analysis defines business context Formulation = a requirements gathering activity o Planning The project plan consists of a task definition & timeline schedule for the time period of an increment o Modeling Rapid analysis & design models are built o Construction WebE tools are applied to construct the WebApp Then a series of rapid tests are conducted o Deployment The WebApp is configured for its operational environment, delivered to users, and evaluated Refining the framework Tasks associated with WebE framework activities may be modified, eliminated, or extended based on the characteristics of the problem, product, project, and people Web engineering best practices 1. Take the time to understand business needs & product objectives, even if the details of the webApp are vague 2. Describe how users will interact with the WebApp using a scenario-based approach 3. Develop a project plan, even if it is very brief 4. Spend some time modeling what it is that youre going to build 5. Review the models for consistency and quality 6. Use tools & technology that enable you to construct the system with as many reusable components as possible 7. Dont rely on early users to debug the WebApp design comprehensive tests and execute them before releasing the system 56

A list of risks that would be likely during the development of a new e-commerce application designed to sell cell phones over the Web o Are users willing to purchase cell phones over the Web? o What will happen if the database fails during operation? o Does the project team possess the technical skills needed? o Does the company have enough staff to assist users? o Will the website be able to handle the projected user load? o Are users subject to abnormal privacy violation risks? o What aspects of the site have the highest security risks?

57