INF305F/501/2009 SWE401I/501/2009 SED401I/501/2009

Advanced Systems Analysis & Development Gevorderde Stelselontleding & Ontwikkeling

TUTORIAL LETTER 501 FOR INF305F/SWE401I/SED401I

CONTENTS/INHOUD: Study Guidelines/ Studieriglyne

SCHOOL OF COMPUTING SKOOL VIR REKENAARKUNDE

Contents
Preface .......................................................................................................................................... 3 How to study for INF305F/SED401I and SWE401I ....................................................................... 4 Study guide format ........................................................................................................................ 4 Chapter 1: Introduction to Software Engineering ........................................................................... 5 Chapter 2: Generic View of Process ............................................................................................. 7 Chapter 3: Prescriptive Process Models ....................................................................................... 9 Chapter 4: Agile Development..................................................................................................... 11 Chapter 5: Practice: A Generic View .......................................................................................... 13 Chapter 6: System Engineering................................................................................................... 15 Chapter 7: Requirements Engineering ........................................................................................ 16 Chapter 8: Analysis Modeling ..................................................................................................... 18 Chapter 9: Design Engineering .................................................................................................. 20 Chapter 10: Architectural Design................................................................................................. 22 Chapter 11: Modeling Component-level Design .......................................................................... 23 Chapter 13: Software Testing Strategies ..................................................................................... 24 Chapter 14: Software Testing Techniques .................................................................................. 26 Chapter 16: Web Engineering ..................................................................................................... 27

INF305F/SED401I/SWE401I/501

Preface
The content of this module is used for INF305F/SWE401I and SED401I. The main code for this course is INF305F. If we refer to INF305F, we also include the other two codes, namely SWE401I and SED401I. According to the IEEE Std 610-1990, software engineering can be defined as: (1) the application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of softwarethat is, the application of engineering to software (2) the study of approaches as in (1) Other definitions available include the following: The system of applying an engineering discipline to the design, implementation and maintenance of software systems. www.cs.ukc.ac.uk/people/staff/djb/book/glossary.html Software engineering is an engineering discipline which is concerned with all aspects of software production from the early stages of system specification through to maintaining the system after it has gone into use. www.resolveit.co.uk/glossary.htm This term refers to a movement, methods and techniques aimed at making software development more systematic. Software methodologies, like the OMG's UML and software tools (see CASE tools) that help developers model application designs and then generate code are all closely associated with software engineering. www.bptrends.com/resources_glossary.cfm A disciplined approach to constructing information systems through the use of common methods, techniques, or tools. myphliputil.pearsoncmg.com/student/bp_jessup_ist_1/JessupGlossary.html A collection of theories, techniques and tools which enable fallible humans to design, construct and maintain large software products in a reliable and cost-effective manner. www.csse.monash.edu.au/~jonmc/CSE2305/General/html/glossary.html A disciplined and standardised approach to program development, both in its managerial and technical aspects. cs.uhh.hawaii.edu/cs/courses/cs100/glossary.htm The application of software design principles to the process of creating software. www.mckinnonsc.vic.edu.au/la/it/ipmnotes/glossary.htm

For the purpose of INF305F, SWE401I and SED401I, we realise that it is not possible to cover all the concepts involved in software engineering. However, we do want to introduce you to some of the

4 more important concepts within software engineering and hope that you will cover the material not discussed in this course in your own time. The goal of this study guide is not to give you additional material to work through. We believe that the prescribed textbook provides you with sufficient material. We will give a short introduction to each chapter and give some answers to selected questions at the end of the chapters. These answers were provided by Pressman and some of them may still be based on the previous version of the textbook. We will consider this when we select questions for examination and if we select from these questions, only those that directly come from the new version of the book will be included.

How to study for INF305F/SWE401I and SED401I

In preparing for the examinations, we recommend that you do the following: 1. Summarise the chapters and learn the theory. 2. Summarise the concepts/definitions within each chapter for shorter theoretical questions in the examination. 3. Work through the questions at the end of the chapters. 4. Work through the questions in the assignments. Our goal is to test your understanding of the concepts and to see if you can apply them to real-life scenarios. Therefore, apart from questions on theory, in the examinations you can also expect questions like the following:
The waterfall model is used in situations where the requirements of a problem are reasonably well understood (Pressman 2005:47). Would you use the waterfall method if you wanted to change the withdrawal limit of a software system for an ATM system?

In this instance, you need to argue, from the given theory in Pressman, whether or not you would use the waterfall method for this specific situation. To be able to do this, you will need to UNDERSTAND the theory, not merely have learned it like a parrot. Do take care in preparing for the examinations and try to understand the concepts rather than learning them by heart.

Study guide format

This study guide gives a short introduction to selected chapters from the prescribed book. The final chapters included for examination purposes will be communicated to you in your general tutorial letters.

INF305F/SED401I/SWE401I/501

Chapter 1: Introduction to Software Engineering

This chapter focuses on some key concepts in software engineering. We include answers to questions 1 and 2 from the end of Chapter 1. 1.1) The definition of software presented in Section 1.2 applies to the web sites. There are, however, subtle differences between a web site and conventional software. Among the most important are that the content that a web site presents is considered to be part of the web application, while that data processed by conventional software is often considered to be separate from the processing functions delivered. It takes software so long to be finished because: a) development facilities are not available online b) development tools do not work as expected c) customers insist on the new requirements, requiring redesign and rework d) products depend on government regulations, which change unexpectedly e) strict requirements for compatibility with existing systems require more testing, design and implementation than expected f) requirements to operate under multiple operating systems take longer to satisfy than expected g) software project risk management takes more time than expected h) dependency on a technology that is still under development extends the schedule Development costs are high because: a) unacceptably low quality requires more rework (design, implementation and testing) than expected b) development of the wrong software functions requires redesign and implementation c) development of the wrong user interface results in redesign and implementation d) development of extra software functions that are not required extends the schedule We cant find errors before we give the software to our customer because: a) products depend on government regulations, which change unexpectedly

1.2)

6 b) products depend on draft technical standards, which change unexpectedly c) new development personnel are sometimes added late in the project d) conflict within teams sometimes results in poor communication and hence poor design e) sabotage by project management results in efficient scheduling and ineffective planning f) sometimes the furnished components are poor quality resulting in extra testing, design and integration work and in extra customer relationship management We continue to have difficulty in measuring progress as software is developed because: a) sometimes the purpose of the project is not clear b) there are a lot of business risks involved c) the project scope is not well-defined d) all work occurs iteratively, hence it is sometimes difficult to define what tasks are being done and when e) good project reporting mechanisms do not exist f) team members refuse to report status

INF305F/SED401I/SWE401I/501

Chapter 2: Generic View of Process

This chapter focuses on the process followed to create a product or system. Software engineers and their managers adapt the process to their needs and then follow it. We include answers to questions 1, 2, 4 and 5 from the end of Chapter 2. 2.1)
Pattern: Intent: Type: Communication To establish a collaborative relationship with the customer in an effort to define project scope, business requirements and other project constraints. Stage pattern

Initial context:

(1) Appropriate stakeholders have been identified and are willing to participate in communication (2) Stakeholders agree that a problem exists and that software may provide a solution

Problem:

Requirements must be elicited from stakeholders and organised in a way that can be used by software engineers. All stakeholders must collaborate to define requirements and to identify those areas where requirements are uncertain. Each stakeholder must develop a description of the functions, features, information and behaviour that are exhibited by the software. To accomplish this, a structured, facilitated meeting is conducted. For more details, see Sections 7.3, 7.4 and 7.5. When this pattern has been successfully completed, basic information required for the development of an analysis model has been acquired and documented in some manner. Usecases (user scenarios) have been developed, along with basic descriptions of system function and behaviour and the data objects that are to be manipulated and/or produced.

Solution:

Resulting context:

Related patterns: Conducting a meeting, requirement gathering, developing use-cases, building a mini-spec, negotiating requirements, prioritisation. Known uses/examples: Communication is mandatory at the beginning of every software project, is recommended throughout the software project and is mandatory once the deployment activity is underway.

2.2)

Process assessment examines the software process used by an organisation to determine whether it is effective in achieving software engineering goals. The assessment characterises the current practice within an organisational unit in terms of the capability of the selected processes. The SPICE (ISO/IEC15504) standard defines a set of requirements for software process assessment. To accomplish the assessment, SPICE specifies a reference model that examines the purpose and measurable objectives of the

8 process (the process dimension) and the set of process attributes that should be present (the capability dimension). 2.4) Task set for communication activity: A task set would define the actual work to be done to accomplish the objectives of a software engineering action. For the communication activity these are as follows: 1. Make a list of stakeholders for the project. 2. Invite all the stakeholders to an informal meeting. 3. Ask them to make a list of features and functions. 4. Discuss requirements and build a final list. 5. Prioritise requirements and note the areas that stakeholders are uncertain of. These tasks may be expanded for a complex software project. They may then consider the following: 2.5) To conduct a series of specification meetings, build a preliminary list of functions and features based on stakeholder input. To build a revised list of stakeholder requirements, use quality function deployment techniques to prioritise the requirements. Note constraints and restrictions on the system. Discuss methods for validating the system.

The CMMI represents a process metamodel in two different waysthe continuous and the staged model. The pros of the CMMI: comprehensive, addressing virtually every aspect of the process; well-organised; adopted widely. The cons: voluminous; overkill for many types of projects; agility is questionable. Although the spirit of the CMMI should always be adopted, each process must be adapted to meet the needs of the project team and to achieve high quality in the end product. The requirements of the CMMI should be applied to all process models, but failure to meet a specific criterion should not necessarily mean that the process is bad. It may be that the CMMI is right in situations in which an organisational culture is amenable to the standard process models and management is committed to making it a success. However, it may be too much for an organisation to successfully assimilate. This means that CMMI which is right for one company culture may not be right for another.

INF305F/SED401I/SWE401I/501

Chapter 3: Prescriptive Process Models

Prescriptive process models define a distinct set of activities, actions, tasks, milestones and work products that are required to engineer high-quality software (Pressman 2005:45). For the examination you need to understand the difference between the different models proposed in the chapter. For this chapter we include answers to questions 1 and 3-8. 3.1) Any software project that has significant functionality that must be delivered in a very tight (too tight) time frame is a candidate for the incremental approach. The idea is to deliver functionality in increments. An example is a sophisticated software product that can be released to the marketplace with only partial functionalitynew and improved versions to follow! For example, word-processing software developed using the incremental paradigm might deliver basic file management, editing and document production functions in the first increment, more sophisticated editing and document production capabilities in the second increment, spelling and grammar checking in the third, and advanced page layout capability in the fourth. The process flow for any increment may incorporate the prototyping paradigm. Incremental development is particularly useful when staffing is unavailable for a complete implementation by the business deadline that has been established for the project. If the plan is to have a prototype evolve into a delivered application, more rigorous design rules and SQA procedures must be applied from the beginning. In addition, the prototype must be designed with extensibility in mind and must be implemented using a programming environment that is amenable to production system development. Initially, the prototype serves as a mechanism for identifying software requirements. Once a working prototype is built, it becomes the skeleton (framework) for extensions that will cause it to evolve into a production system. RAD assumes that a project can be modularised in a manner that allows major functionality to be delivered within a 60 90 day time frame. Although this is often the case, there are situations in which timelines are longer. In addition, RAD assumes that sufficient human resources will be available to develop the increments in parallel. This may not be the case. Software applications that are relatively easy to prototype almost always involve humanmachine interaction and/or heavy computer graphics. Other applications that are

3.3)

3.4)

3.5)

10 sometimes amenable to prototyping are certain classes of mathematical algorithms, subsets of command-driven systems and other applications where results can be easily examined without real-time interaction. Applications that are more difficult to prototype include control and process control functions, many classes of real-time applications and embedded software. 3.6) The real question that a paper should address is: How do we develop a process that can accommodate many of the chaotic attributes of modern software development? The authors suggest processes that are focused on flexibility and extensibility rather than on high quality and admit that this approach is scary. No doubt! In fact, I believe it is a recipe for disaster. With the exception of certain widely used PC operating systems (that will remain nameless), quality does appear to be a reasonable harbinger of successful software. A program that is flexible and extensible will not succeed if it fails regularly and behaves unpredictably. It should be noted that much has been written about good enough software. Thats OK as long as the word good is emphasised. Process models can be combined. Each model suggests a somewhat different process flow, but all perform the same set of generic framework activities: communication, planning, modelling, construction and deployment. For example, the linear sequential model can serve as a useful process model in situations where requirements are fixed and work is to proceed to completion in a linear manner. In cases where the developer may be unsure of the efficiency of an algorithm, the adaptability of an operating system, or the form that human-machine interaction should take, etc., a prototyping model may offer the best approach. In other cases, an incremental approach may make sense and the flow of spiral model may be efficient. Special process models take on many of the characteristics of one or more of the tradition. 3.8) A software engineering workflow is distributed across all UP phases. In the context of UP, a workflow is analogous to a task set. That is, a workflow identifies the tasks required to accomplish an important software engineering action and the work products that are produced as a consequence of successfully completing the tasks. UP workflow is conducted for every software project, whereas the five UP phases do not necessarily occur in a sequence, but rather with staggered concurrency. It is likely in the UP that at the same time the construction, transition and production phases are being conducted, work may have already begun on the next software increment.

3.7)

11

INF305F/SED401I/SWE401I/501

Chapter 4: Agile Development

For this chapter it is important that you know what agility is, what an agile process is and what the agile process models are. We include answers to questions 1-8. 4.1) An agility principle noted in Section 4.2.1 is: Welcome changing requirements, even late in development. Agile processes embrace change as essential to the customer's competitive advantage. Each of the process models presented in this chapter exhibits this principle. One more agility principle that would help a software engineering team become even more manoeuvrable would be: A team should know whose skills suit a particular project, and get these people on their project, for software development to become more effective. Another might be: Communication is the key, the consumer and developer should communicate regularly even if they are geographically separated. The generic process framework can be applied to each agile process described in this chapter. The table should list all agile process models across the first row and all generic framework activities (communication, planning, modelling, construction, deployment) down the first column. Review each agile process description to select the name of the analogous process activity, e.g.: communication XP: planning - user stories planning XP: planning commitment to a specific increment modelling XP: design, spike solutions, refactoring construction XP: pair programming, unit testing deployment XP: acceptance testing, customer tests 4.4) The software team manages change by focusing on a defined increment (i.e. the scope of the increment is defined) and postponing any changes until the next increment. All agile process models are iterative/incremental. For example, ASD uses an iterative process that incorporates adaptive cycle planning, relatively rigorous requirement gathering methods, and an iterative development cycle that incorporates customer focus groups and formal technical reviews as real-time feedback mechanisms. The dynamic systems development method (DSDM) defines three different iterative cyclesfunctional model iteration, design

4.2)

4.3)

12 and build iteration, and implementation preceded by two additional life cycle activities feasibility study and business study. 4.5) Agility can be applied to any software process. However, to accomplish this, it is essential that the process 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 and keep them lean, and emphasise an incremental delivery strategy that gets working software to the customer as rapidly as is feasible for the product type and operational environment. Each of the four values is commendable, but each can get a team into trouble. For example, people and their interactions are very important, but a complex project may fail because the technology brought to bear is insufficient (e.g. processes and tools are poor). Working software is, undoubtedly, the bottom line, but tell that to someone who must maintain an application three years after everyone on the team has moved on. Collaboration is commendable, but negotiation helps avoid unrealistic expectations and, in the worst case, litigation. Responding to change is paramount, but a chaotic project environment (no plan) leads to failure in many cases. Requirements change so much because it is difficult to predict in advance which software requirements will persist and which will change. It is equally difficult to predict how customer priorities will change as the project proceeds. It is often difficult for people to verbalise their software needs until they see a working prototype and realise that they had forgotten to consider something important.

4.6)

4.7)

4.8)

Physical proximity is important. A question gets an immediate answer; a concern can be discussed without delay; negotiation occurs in unplanned (and therefore effective) personal communication. You cant beat it! However, physical proximity is not always possible. Most agile process models recommend face-to-face communication. Today, this 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 accomplish much the same result.

13

INF305F/SED401I/SWE401I/501

Chapter 5: Practice: A Generic View

Practice is a broad array of concepts, principles, methods and tools that you must consider as software is planned and developed (Pressman 2005:71). For examination purposes it is important that you know the concepts within all the practices discussed in Chapter 5, including: software engineering practices communication practices planning practices modelling practice construction practice

deployment In this study guide we include answers to questions 1-8. 5.1) Facilitation for the communication activity is essential as requirements are gathered. Every communication meeting should have a leader (a facilitator) (1) to keep the conversation moving in a productive direction; (2) to mediate any conflict that does occur; (3) to ensure that other principles are followed. Sample guidelines are as follows: 5.2) Understand the business domain. Know who the stakeholders are and what goals each has. Establish a defined requirements gathering mechanism. Create a method for recording requirements. Establish a way to prioritise needs.

Technical essentials that might be recommended for software engineering include the need to (1) thoroughly test software with the intent of finding errors; (2) use automated tools to facilitate development and improve technical insight; (3) measure the product and use those measures to improve technical quality. Management essentials that might be recommended for software engineering include (1) continuing and effective communication with all stakeholders; (2) implementation of an agile mindset regardless of the process model that is chosen; (3) a set of management and technical practices that enable the software team to define a road map as it travels toward its ultimate goal. An important communication principle states that you need to prepare before you

5.3)

5.4)

14 communicate. Customer communication principles and concepts focus on the need to reduce noise and improve bandwidth as the conversation between developer and customer progresses. Both parties must collaborate for the best communication to occur. To achieve this, the software engineer must (1) research the business domain that the software will address; (2) understand the players (i.e. the stakeholders) who will specify requirements; (3) develop a defined strategy for requirements gathering; (4) understand the goals for each of the stakeholders; (5) understand that negotiation will occur. 5.5) Analysis models represent the customer requirements by depicting the software in three different domains: the information domain, the functional domain and the behavioural domain. Design models represent characteristics of the software that help practitioners to construct it effectively: the architecture, the user interface and component-level detail. Negotiation for the communication activity works best when both parties win. Sample guidelines include the following: Establish that were all on the same team and each of us has the same goalto produce a system that meets users needs. Always try to find common groundwhat do we agree on? Recognise that each side will have to compromise. Never get personal or recriminatekeep the discussion about the software. Granularity refers to the level of detail that is introduced as a project plan is developed. A fine granularity plan provides significant work task detail that is planned over relatively short time increments (so that tracking and control occur frequently). A coarse granularity plan provides broader work tasks that are planned over longer periods. In general, granularity moves from fine to coarse as the project timeline moves away from the current date. The agile view of customer communication and collaboration emphasises the need for all stakeholders to work (continuously) as a team, be co-located and recognise that change is part of the process. However, the basic agile philosophy of communication is applicable to all software engineering practice and, like all software engineering practices, communication and collaboration are iterative. Each iteration divulges important new information and enhances the overall understanding of the software to be built.

5.6) 5.7)

5.8)

15

INF305F/SED401I/SWE401I/501

Chapter 6: System Engineering

This chapter focuses on system engineering. System engineering is done by the system engineer who works to understand system requirements by working with the customer, future users and other stakeholders. For this chapter we include answers to questions 1, 2 and 4. 6.1) 6.2) Draw a hierarchy similar to those represented in Figures 6.1 to 6.3. You might suggest the following systems: an airport, your university, an online bank, a retail store, an e-commerce site. As an example consider a university: University Academic programmes Degree granting programmes undergraduate Degree granting programmes postgraduate Professional education Continuing education Administrative departments Registrar . Courses Faculty Infrastructure maintenance The data architecture refers to corporate data, its organisation and the relationships between individual corporate data elements. For example, a telephone billing system might draw on elements that include customer information, rate tables, calling logs and so forth. Application architecture defines the functional hierarchy that is required to realise the goals and objectives of a large information system. Technology infrastructure identifies the hardware and software backbones (e.g. client/server, operating system type) that enable the system to function.

6.4)

16

Chapter 7: Requirements Engineering

Requirements engineering helps software engineers to gain a better understanding of the problem they will be working to solve. It encompasses the set of tasks that lead to an understanding of what the business impact of the software will be, what the customer wants and how end-users will interact with the software (Pressman 2005). For the purposes of INF305F, SWE401I and SED401I, you need to know what requirements engineering is and what the important concepts and tasks involved in it are. After completing the second-year modules, you should be able to use object-oriented concepts such as the application of use-case scenarios described in Section 7.5. You must know what is involved in building an analysis model and also the important issues involved in validating requirements (Section 7.8). We include answers to questions 2-7. 7.2) In reality, the customer and the developer enter into a process of negotiation, where the customer may be asked to balance functionality, performance and other product or system characteristics against cost and time to market. The intent of this negotiation is to develop a project plan that meets the needs of the customer while at the same time reflecting the real-world constraints (e.g. time, people, budget) that have been placed on the software team. Unfortunately, each customer has his/her own priorities and views. These views are not necessarily consistent. Feasibility analysis within the context of the inception function is to identify a working description of the projects scope and then assess whether the scope can be achieved within the context of management and technical constraints. In essence, feasibility analysis (during inception) defines a business case for an idea and identifies the breadth and depth of the market that the product is to address. You might try using an approach like QFD that makes use of customer interviews and observation, surveys and examination of historical data (e.g. problem reports) as raw data for the requirements gathering activity. These data are then translated into a table of requirementscalled the customer voice tablethat is reviewed with the customers later. A variety of diagrams, matrices and evaluation methods are then used to extract expected requirements. However, if the customer refuses to work with you, it is time to get both your management and the customers management involved. If they dont have the time to help define the software, they probably wont have the inclination to use it.

7.3)

7.4)

17

INF305F/SED401I/SWE401I/501

7.5)

Software engineers want to begin building something, so they sometimes give requirements analysis short shrift. In addition, understanding the requirements of a problem is among the most difficult tasks that a software engineer faces since requirements change, are sometime contradictory and are often difficult to enunciate clearly. Hence, software engineers want to get through the requirements engineering activity and get on with the real engineering work. A mistake! In situations in which 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.

7.6)

Guidelines should be consistent with information presented in Section 7.4 and should stress establishing a collaborative atmosphere. To summarise: Meetings are conducted and attended by both software engineers and customers. Rules for preparation and participation are established. An agenda is suggested that is formal enough to cover all important points but informal enough to encourage the free flow of ideas. A facilitator (can be a customer, a developer, or an outsider) controls the meeting. A definition mechanism (can be worksheets, flip charts, or wall stickers or an electronic bulletin board, chat room or virtual forum) is used. The goal is to identify the problem, propose elements of the solution, negotiate different approaches and specify a preliminary set of solution requirements in an atmosphere that is conducive to the accomplishment of the goal.

7.7)

The first set of context-free questions focuses on the customer and other stakeholders, the overall goals and the benefits. For example, the requirement engineer might also ask: Who is paying for this work? What is the name of a contact person in each customer group? Do you know of any other business that has solved this problem successfully?

18

Chapter 8: Analysis Modeling

Analysis modelling uses a combination of text and diagrammatic forms to depict requirements for data, function and behaviour in a way that is relatively easy to understand and, more importantly, straightforward to review for correctness, completeness and consistency (Pressmann 2005). The analysis model can be seen as the bridge between the system description and the design model (Pressman, Figure 8.1). We expect you to be able to differentiate between the different analysis modelling approaches and the concepts involved in these approaches. We might expect you to develop some of the diagrams included in the chapter from real-life scenarios to illustrate your understanding of the concepts. We will expect you to be able to define classes similar to the ones in Section 8.7 and also to use and define the concepts in this section. Lastly, you should be able to understand the behavioural models described in Section 8.8. We include answers to questions 1-9 at the end of Chapter 8. 8.1) Structured analysis begins with a consideration of the data objects that the system must manipulate. In structured analysis the data objects are described with a data dictionary and the entity relation diagram (ERD) depicts relationships between data objects. The flow and transformation of data through a system are represented using the data flow diagram (DFD). The structured analysis also incorporates a behavioural modelling notation called the state transition diagram (STD). In the object-oriented (OO) analysis model, classbased elements model the objects that the system will manipulate, the operations that will be applied to the objects to effect the manipulation, relationships (some hierarchical) between the objects, and the collaborations that occur between the classes that are defined. In addition, the OO model represents the behaviour of objects and of the system as a whole.

8.2)

It is possible to develop an effective analysis model without developing all four elements shown in Figure 8.3. However, each element presents a different view of the problem to be solved, and therefore provides the ability to see potential problems, inconsistencies or omissions more clearly. In addition, if all four elements of the analysis model are developed, the transition to design is simplified.

8.3)

The analysis model will serve as the basis for the 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

19

INF305F/SED401I/SWE401I/501

a haphazard manner and global data structures will not have been explicitly designed. 8.4) Domain analysis is an ongoing software engineering 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 characterise the domain. Many infrastructure requirements are not visible in the problem or business domain, for example what functions are required to manage global data, what functions are required to implement network communication and what functions are required to implement a user interface. Be certain to emphasise the fact that all data-objects and relationships MUST be customer visible. Attributes should be reviewed to be certain that they properly reflect the requirements of the system. At context level, be certain to show external entities, major input and output data objects and a major data store (e.g. a database) that is externally visible to users of the system. The various elements of the analysis model (e.g. use-cases, analysis classes) are categorised in a manner that packages them as a groupingcalled an analysis package. To illustrate the use of analysis packages, consider the video game discussed briefly in this chapter. As the analysis model for the video game is developed, a large number of classes are derived. These can be grouped as a series of packages. The CSPEC should focus on the behavioural aspects of the system. First, you must identify the events that cause the system to behave in a specific manner. Next, you will have to represent the manner in which events are handled (the CSPEC). PSPECs are developed for every bubble at the lowest level of the DFDs. The PSPEC should describe the processing performed by the bubble (transform). Be sure to emphasise the importance of a hierarchical approach to function partitioning when functions are defined.

8.5)

8.6)

8.7)

8.8)

8.9)

20

Chapter 9: Design Engineering

Design is what virtually every engineer wants to do. It is the place where creativity ruleswhere customer requirements, business needs and technical considerations all come together in the formulation of a product or system (Pressman 2005). For the purpose of this module, we need you to understand the context of design within the software engineering discipline. You must understand the concepts involved in the design process and design quality. Not only do you need to understand the design concepts, but you must also be able to differentiate between the analysis and design models, as discussed in Section 9.4. We include answers to questions 1-3 and 5-7 at the end of Chapter 9. 9.1) 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 or product. The goal of design is to create a model of software that will implement all customer requirements correctly and bring delight to those who use it. Yes, but the design is conducted implicitlyoften in a haphazard manner. During design (in a software engineering context) we develop representations (models) of programsnot the programs themselves.

9.2)

9.3)

Software architecture is the structure or organisation of program components (modules), the manner in which these components interact and the structure of data that are used by the components. In a broader sense, however, components can be generalised to represent major system elements and their interactions.

9.5) 9.6) CreditCard validate; check-limit; charge-against scale; draw; revise

EngineeringDrawing WebSite

add-page; access; add-graphic

We create a functional hierarchy and as a result refine the problem. For example, considering the check (cheque) writer, we might write: Refinement 1:

21 o Write dollar amount in words Refinement 2: o Procedure write amount; o Validate amount is within bounds; o Parse to determine each dollar unit; o Generate alpha representation; end write_amount Refinement 3: o procedure write_amount; do while checks remain to be printed if dollar amount > upper amount bound

INF305F/SED401I/SWE401I/501

then print "amount too large error message; else set process flag true; endif; determine maximum significant digit; do while (process flag true and significant digits remain) enddo print alpha string; enddo o end write_amount 9.7) In some time-critical applications, monolithic implementation may be required. However, design can and should occur as if the software were to be implemented modularly. Then "modules" are coded in-line. set for corresponded alpha phrase; divide to determine whole number value; concatenate partial alpha string; reduce significant digit count by one;

22

Chapter 10: Architectural Design

Architectural design represents the structure of data and program components that are required to build a computer-based system. It considers the architectural style that the system will take, the structure and properties of the components that constitute the system and the interrelationships that occur among all architectural components of a system (Pressman 2005). For examination purposes you only need to reflect on what architecture is and what data design and architectural styles and patterns are. No questions will be asked from the remaining section, although we seriously recommend that you read it for your own knowledge and application during software development. We include answers to questions 1-5 at the end of Chapter 10. 10.1) Any application that does an engineering or scientific computation tends to have transform characteristics. Once you choose an application, map as described in this chapter.

10.2) A paper on this subject should begin with any good data structures textbook, delineate the available data structure options and then connect them to actual application. Lets assume that you are building a CAD system in which various components (mechanical, electronic) can be placed within the design architecture at different times. A list of all components must be maintained and organised by architectural subsystems, by type and other categories. It might be useful to select a series of linked lists (a data structure) to accomplish this (other alternatives are also possible).

10.3) A data warehouse is a global repository for information gathered from many corporate sources (databases). A database is generally a single data store that addresses a specific set of information needs within a business.

10.4) Most interactive applications have distinct transaction characteristics. Once you choose an application, map as described in this chapter.

10.5) Hierarchical: dataflow, call return, layer Non-hierarchical: data-centred, object-oriented Non-hierarchical architectures are probably best implemented using object-oriented and event-driven programming techniques.

23

INF305F/SED401I/SWE401I/501

Chapter 11: Modeling Component-level Design

Modelling component-level design includes the design of a complete set of software components during architectural design. Component-level design defines the data structures, algorithms, interface characteristics and communication mechanisms allocated to each software component. We include answers to questions 1-4. 11.1) Guard-condition is written in Object Constraint Language (OCL) and specifies a condition that must be met before the event can occur, and action expression defines an action that occurs as the transition takes place. Like object-oriented components, traditional software components are derived from the analysis model. In this case, however, the data flow-oriented element of the analysis model serves as the basis for the derivation. Each transform (bubble) represented at the lowest levels of the data flow diagram is mapped (Section 10.6) into a module hierarchy. Control components (modules) reside near the top of the hierarchy (architecture) and problem domain components tend to reside toward the bottom of the hierarchy. To achieve effective modularity, design concepts like functional independence are applied as components and elaborated. The open-closed principle (OCP) states that module [component] should be open for extension but closed for modification. The designer should specify the component in a way that allows it to be extended (within the functional domain that it addresses) without the need to make internal code abstractions that serve as a buffer between the functionality that is likely to be extended and the design class itself. External coupling occurs when a component communicates or collaborates with infrastructure components (e.g. operation system functions, database capability, telecommunication functions). Although this type of coupling is necessary, it should be limited to a small number of components or classes within a system. Software must communicate internally and externally. Therefore, coupling is a fact of life. However, the designer should work to reduce coupling whenever possible and understand the ramifications of high coupling when it cannot be avoided.

11.2)

11.3)

11.4)

24

Chapter 13: Software Testing Strategies

Software is tested to uncover errors that were made inadvertently as it was designed and constructed. During the development of a software testing strategy, questions such as: How do you conduct the tests? and Should you test the entire program as a whole or run tests only on a small part of it? are answered (Pressman 2005). For the purposes of INF305F, SWE401I and SED401I you should know the concepts and issues involved in software testing strategies and be able to distinguish between the different strategies for different types of development platforms. You should also be familiar with the concept of validation testing and system testing. Lastly, you should know the concepts involved in debugging. We include answers to questions 1-5 and 7-10 from the end of Chapter 13.

13.1)

The most common problem in the creation of an ITG is getting and keeping good people. In addition, hostility between the ITG and the software engineering group can arise if the interaction between groups is not properly managed. Finally, the ITG may get involved in a project too latewhen time is short and a thorough job of test planning and execution cannot be accomplished. An ITG and an SQA group are not necessarily the same. The ITG focuses solely on testing, while the SQA group considers all aspects of quality assurance.

13.2)

Verification focuses on the correctness of a program by attempting to find errors in function or performance. Validation focuses on conformance to requirementsa fundamental characteristic of quality.

13.3)

A highly coupled module interacts with other modules, data and other system elements. Therefore its function is often dependent on the operation of those coupled elements. In order to thoroughly unit test such a module, the function of the coupled elements must be simulated in some manner. This can be difficult and time consuming.

13.4)

Developer, if customer acceptance test is planned. Both developer and customer (user), if no further tests are contemplated. An independent test group is probably the best alternative here, but it isnt one of the choices.

25 13.5)

INF305F/SED401I/SWE401I/501

It is not always possible to conduct thorough unit testing in that the complexity of a test environment to accomplish unit testing (i.e. complicated drivers and stubs) may not justify the benefit. Integration testing is complicated by the scheduled availability of unit-tested modules (especially when such modules fall behind schedule). In many cases (especially for embedded systems) validation testing for software cannot be adequately conducted outside of the target hardware configuration. Therefore, validation and system testing are combined.

13.7)

The availability of completed modules can affect the order and strategy for integration. Project status must be known so that integration planning can be accomplished successfully.

13.8)

A single rule covers a multitude of situations: All data moving across software interfaces (both external and internal) should be validated (if possible). Advantages: Errors don't "snowball". Disadvantages: Does require extra processing time and memory (usually a small price to pay).

13.9)

Use the analysis and design models as a guide. In general, begin by considering the major functions and features for SafeHome and suggest tests to address them. Then elaborate major functions and features and refine tests as you go. Specific answers will vary.

13.10) No. If a module has three or four 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.

26

Chapter 14: Software Testing Techniques

Software testing techniques provide systematic guidance for designing tests that exercise (1) the internal logic and interfaces of every software component and (2) the input and output domains of the program to uncover errors in program function, behaviour and performance (Pressman 2005). For the purposes of INF305F, SWE401I and SED401I we only cover Sections 14.1-14.3. You need to study the software testing fundamentals and know what white box and black box testing are. We include answers to questions 2 and 4-6 at the end of Chapter 14. 14.2) For specific input, an error occurs internally resulting in: 1) improper data placed in a global data area 2) improper flags that will be tested in a subsequent series of tests 3) improper hardware control that can only be uncovered during system test; yet "correct" output is produced Be certain that you consider compound conditions in the source code and represent the flow graph properly. Because each subclass of a given class is applied within the context of private attributes and operations (and the fact that these private attributes and operations can add complexity), subclasses must be retested in their operational context. Test cases can be reused, but it is important to extend them to address the private attributes and operations of the subclass. In addition to those objectives, a successful test: a) demonstrates compliance with function and performance b) uncovers documentation errors c) uncovers interfacing problems d) demonstrates an understanding of program architecture, data structure, interface design and procedural design e) establishes an entry into a test case database that may later be used for regression testing

14.4)

14.5)

14.6)

27

INF305F/SED401I/SWE401I/501

Chapter 16: Web Engineering

WebE (Web engineering) is the process that is used to create high-quality WebApps (Web applications). WebE is not a perfect clone of software engineering, but it borrows many of software engineerings fundamental concepts and principles (Pressman 2005). For INF305F, SWE401I and SED401I we need you to study Chapter 16 and make sure that you understand the concepts given in the chapter. We give answers to questions 1-7 at the end of the chapter. 16.1) The key here is to recognise that "content" spans a wide array of media including text, graphics, animation, audio and video. Even within a specific media type (e.g. video), we encounter many different formats and presentation modes. There may be one or two late-breaking technologies that may be of more interest. Feel free to choose what interests you. Answers will vary in that every person has a different perception of WebApp quality. In addition to the attributes noted at the beginning of this chapter, WebApps have the following specialised characteristics: Customisable each user is often given the opportunity of customising the information presented to his/her own needs. Dependent (interoperable) the content of the WebApp may be dependent on the content of other WebApps (e.g. hot links to other web sites) that are not under the control of the WebApp developer. Responsive users can comment on the WebApp in real-time and expect a timely response to their query/comments.

16.2)

16.3) 16.4)

16.5)

The principle that would work well for a two-year e-project (involving dozens of people) that will build a major e-commerce system for an automobile company would be: Continuous attention to technical excellence and good design enhances agility. This is the basis of many good engineering practices. The metrics of technical excellence and good design are not stated, leaving them open to interpretation.

28 The principle that would work well for a two month e-project that will build an informational site for a small real estate firm would be: Business people and developers must work together daily throughout the project. This is common business practice in successful organisations. The definition of customer is restrictive in many of the agile process methods, especially when building products rather than projects. The granularity of the interaction is the issue. If the customer is co-located, direct daily interaction is possible. If not, then some other form of communication is necessary. Documentation then plays a more significant role. 16.6) Answers will vary but several important risks that should be considered during the development of a new e-commerce application designed to sell mobile phones and service directly over the Web would be: Are users willing to purchase mobile phones and services over the Web? What will happen if the database used to support the WebApp fails during operation? Does the project team possess the technical skills needed to implement the application? Does the company have the user support staff needed to assist users who have problems using the system to order mobile phones and services? Will the web site be able to handle the projected user load? Are users subject to abnormal privacy violation risks as a result of using this system? What aspects of the site have the highest security risks?

16.7)

WebE process models (discussed in detail in Section 16.3) embrace the agile development philosophy (Chapter 4). Agile development emphasises a lean development approach that incorporates rapid development cycles. Even when rapid cycle times dominate development thinking, it is important to recognise that the problem to be solved must still be analysed, a design should be developed, implementation should proceed in an incremental fashion, and an organised testing approach must be initiated. However, these framework activities must be defined within a process that (1) embraces change; (2) encourages the creativity and independence of development staff and strong interaction with WebApp stakeholders; (3) builds systems using small development teams, and (4) emphasises evolutionary or incremental development using short development cycles.

Unisa @ 2009