TRY & TRY U WILL BE SUCCESS - dizworld.comdizworld.com/dizyDownload/SE.docx · Web viewDevelopers must use methods of planning, analysis, design ... ( Instead of using Oracle

TRY & TRY U WILL BE SUCCESS

Software Engineering

SANJAY HIRANISemester: 5th

Branch:MCA

Software Engineering (SANJAY HIRANI) Page 1


Chapter 1 - Software and Software Engineering

1.1 The Nature of Software

Today, software takes on a dual role. It is both a product and a vehicle for delivering a product. It is a product which you can buy (license). As a product it allows you to use the power of hardware. (OS, drivers etc) It also allows you to deliver the most important product of our time – information. Software which is a product creates, stores, transmits, displays information which is again a product.

Over the last 50 years the roles of computers and computer software have undergone a significant change. From simple systems with limited capacity to store and process information using primitive devices they have grown to highly sophisticated and complex systems using exotic I/O devices and vast increases in storage and processing capacities. Keyboard, mouse, joystick, touchpad, microphone, scanner, HD, tape, CD, pen drive, monitor, printer, plotter, speaker, TV.

People have talked about “the third wave of change”, “information society”, “democratization of knowledge”, etc. From a single programmer developing a system now we have teams of specialists for doing every different task. But, the problems faced and questions raised are still more or less same. And hence it is necessary to understand and use the concepts of software engineering.

What is software ? It is a PRODUCT. Like soap, car, ice cream

Who builds it ? S/W Engineers design and build it.

For whom ? For everybody. Because it does affect everybody.

Directly or indirectly. How? Train reservation.

Weather forecast, State/Central budgets,

budget of USA, R & D in medicine /

pharmaceutical industry.

Since the software one develops affects everybody directly or indirectly it has to be developed right -meaning by applying engineering approach – systematically and in disciplined way. If you don’t then

1. It will not get finished on time2. There will be cost overrun3. There will be errors4. Ultimately it will not meet the basic objective it was supposed to meet.



In order to develop / manufacture a product you need to understand the characteristics of the product (in our case - software ). What is it actually ? What does it consist of ? For example, before you manufacture a car you need to know that car is meant for transportation of people. It consists of engine , body , radiator, carburetor, wheels/tyres , steering wheel , seats , etc.

1.1.1 Defining Software Software consists of

1. Programs – they provide desired function when executed.2. Data structures that enable programs to manipulate information.3. Documents that describe the use and operation of the programs. Operating instructions ,

technical manuals. If we take an example of microwave oven or a PC , the manual for operating instructions and the technical manual for maintenance and repairs is also part of the product. One demands manual with products like TV, car, PC, cell phone, washing machine etc.

Characteristics of software (Comparison with other products)

1. Software is developed and not manufactured . In manufacturing of a hardware product , in spite of good design the quality may not be good due to improper manufacturing. But, in software product there is very little scope of quality problems during development. Therefore major effort and cost are concentrated in engineering or development and hence s/w projects can not be managed as manufacturing projects, they have to be treated differently.

2. Software does not “wear” out (fail) like hardware . In mechanical products the failure curve is bathtub shaped. The failure rate is high during early life due to design/manufacturing defects. Then it bottoms out and remains steady for a long time. Again ,towards the end of the life the failure rate increases. In software products the failure rate is high in the beginning but then it drops after sometime and then increases steadily again as minor changes are required from time to time.

Failure curve for hardware:



Failure curve for software:

idealized curve

change

actual curve

Failurerate

Time

increased failurerate due to side effects

3. In hardware products there are spare parts and you can replace them as and when they fail. Hard disk, carburetor, compressor etc. In software products there are no replaceable spare parts.

4. Software maintenance is more complex than hardware maintenance .



5. Most software is custom built . Component based assembly is still not prevalent. IBM PC was based on off the shelf parts. The beauty was in the idea of a PC. Reusable components help the engineer in using his/her imagination in innovative design rather than in designing not so important components. The software industry is slowly moving towards it. Godrej furniture.

1.1.2 Software Application Domains

For transportation of goods and people you have number of different types of products like bullock / camel carts , bicycle , scooter / motor cycle , car , bus , truck , train , golf cart , aircraft , boats , ships etc. They all serve different purpose. Similarly there are number of different types of s/w applications which serve different purposes. They are as follows :

1. System Software : Collection of programs written to service other programs i.e. editors , compilers , operating systems , drivers etc. They interact with the hardware , have heavy usage by multiple users , have concurrent operation that requires scheduling , resource sharing etc.

2. Application software – stand-alone programs that solve a specific business needs. - Payroll , invoicing , ERP , Inventory , airline / train reservation etc.

3. Engineering and scientific : has been characterized by “Number crunching” algorithms. Volcanology , weather forecasting , molecular biology.

4. Embedded software : resides within a product or system and is used to implement and control features and functions for the end user and for the system itself. Resides in ROM in devices. Microwave ovens , washing machines , dishwashers , cell phones.

5. Product Line software : designed to provide a specific capability for use by many different customers. Product-line software can focus on a limited and esoteric marketplace (e.g., inventory control products) or address mass consumer markets (e.g., word processing, spreadsheets, computer graphics, multimedia, entertainment, database management, and personal and business financial applications).

6. Web based software : Web pages you receive are also software. They have executable instructions (CGI , HTML ) and data.

7. Artificial intelligence software : make use of Non-numerical algorithms to solve complex problems. Robotics, Expert systems , voice recognition , game playing, artificial neural networks etc.

New Challenges

Software engineers are facing lot of challenges related to legacy software – software developed few years ago. But, there are new challenges which have appeared on the horizon. Some of these are :

Open World Computing The rapid growth of wireless computing may lead to distributed computing. You do not need to be connected to the network by wires. Small devices (even



mobile phones) will be able to get connected to the network and the challenge will be to develop software useful on such devices. Speed, security, screen size, band width.

Netsourcing Developing applications to run on WWW which can be used by end users all over the world. Languages, date formats, separators

Open Source where the source code is available for customers to make changes. The challenge is to build source code that is self descriptive so that those who wish to change it can do it easily.

New Economy The economy based on ICT (information and communication technology) is called the new economy as compared to the manufacturing based economy which is now called old economy. The new economy was at peak in 1990s but then the bubble burst in the early 2000. Lot of people thought that the new economy is dead but once again we can see that it is well and alive and is evolving (Internet 2.0, new apps etc). The challenge is to develop applications that will allow mass communication and distribution using concepts which are evolving now. Social networking, web services.

1.1.3 Legacy Software

software programs developed few years ago are called legacy software. These software programs have been modified number of times over a period of number of years since they are critical for the business. Because of this criticality they have been in use for a long period. Many of them have one characteristic in common and that is poor quality. Some of the reasons for the poor quality are inextensible design, poor or nonexistent documentation, poorly managed change history etc. As long as they serve their main purpose they should be used but then they will need to evolve to take care of changes in technology and changes in business requirements. You have to reengineer the system to keep it viable into the future. (Development of entirely new software will most of the times be very expensive). So the goal of modern software engineering is to “device methodologies that are founded on the notion of evolution”; that is, the notion that software systems continually change, new software systems are built from the old ones, and all must interoperate and cooperate with each other.

1.2 The Unique nature of WebApps

In the early days of WWW (1990-1995) websites consisted of little more than a set of linked hypertext files that presented information using text and limited graphics. Then HTML got augmented by XML, Java etc which enabled Web Engineers to provide computing capability along with informational content. WebApps (Web based systems and applications) were born. Today, WebApps have evolved into sophisticated computing tools that not only provide stand-alone function to the end user but also have been integrated with corporate databases and business applications.



These WebApps are different from other types of applications discussed earlier. The following attributes are encountered in the vast majority of WebApps.

Network Intensiveness, Concurrency, Unpredictable load, Performance, Availability, Data Driven, Content sensitive, Continuous evolution, Immediacy, Security, Aesthetics.

Network intensiveness

By its nature, a WebApp is network intensive. It resides on a NETWORK, INTERNET, INTRANET or an EXTRANET and must serve the needs of a diverse community of clients.

Concurrency

A large number of users may access the WebApp at one time and the pattern of usage will vary greatly.

Unpredictable load

The number of users may vary by orders of magnitude from day to day – 100 on one day 10,000 on the next day.

Performance

Fast response is must otherwise the user may go to other sites.

Availability

100 % availability is expected i.e. 24 / 7 / 365. Cannot be shut down for maintenance in USA at night because it will be day time in Asia and Asian users may be using it.

Data Driven

The primary function of many WebApps is to use hypermedia to present text, graphics, audio, video content to the end user. In addition, WebApps are commonly used to access information that exists on databases that are not an integral part of the Web environment e.g. e-commerce or financial applications. Vadilal – Order processing.

Content sensitive

Bad content or presented poorly - no visitors.

Continuous evolution

Unlike conventional application software that evolves over a series of planned, chronologically spaced releases, web application evolves continuously. It is not unusual for some WebApp to be updated on hourly schedule. Homepages of Rediff, IndiaTimes etc.



Immediacy

WebApps have immediacy. It is not found in any other type of software. Time to market is in days. Developers must use methods of planning, analysis, design, implementation, and testing that have been adapted to the compressed time schedules required for WebApps development.

Security

Because WebApps are available via network access, it is difficult, if not impossible , to limit the population of end-users who may access the application. In order to protect sensitive content and provide secure mode of transmission, strong security measures must be implemented throughout the infrastructure that supports a WebApp and within the application itself.

Aesthetics

An undeniable part of the appeal of a WebApp is its look and feel. When a application has been designed to market or sell products or ideas, aesthetics may have as much to do with success and technical design.

1.3 Software Engineering

In order to build software that is ready to meet the challenges of the 21st century , one must recognize a few simple realities :

1. Software has become deeply embedded in virtually every aspect of our lives (cell phone, TV, washer, Car, bank, utility billing, travel , education, medicine ….), and as a consequence, the number of people who have an interest in the features and functions provided by a specific application has grown dramatically. And all these people have different ideas and requirements. Hence, a concerted (intensive) effort should be made to understand the problem before a software solution is developed.

2. Software has become complex and it requires interaction between its various components. (ERP) Design activity becomes a pivotal activity.

3. Everybody and every organization relies on software for day-day-to operations, tactical and strategic decision making. Poor quality of software can have catastrophic effects. Hence, software should exhibit high quality.

4. With growth in User base and longevity software needs to be adapted and enhanced continuously. Hence it should be maintainable (easy to correct and improve).

These simple realities lead to one conclusion : software in all its forms and across all of its application domains should be engineered.



Like so many other subjects there is no one precise definition of software engineering but every definition helps you in understanding what the subject is about. Some of the definitions are as follows:

- Software engineering is the establishment and use of sound engineering principles in order to obtain economical software that is reliable and works effectively on real machines.

- Software Engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software i.e. application of engineering to software.

You can look at software engineering from different angles but the main focus is on quality. If the quality of software is not good, the customers would not be satisfied and your efforts would be wasted.

Software engineering can be seen as consisting of different layers. There are 3 layers. Processes , Methods and tools. As shown in the following figure:

a “quality” focus

process model

methods

tools

The first one is the layer of processes / activities. The activities or processes are also called Key Process Areas (KPAs). Some of them are Software configuration management , s/w quality assurance , s/w project planning , requirements management , intergroup coordination , training program , s/w quality management.

The second layer is software methods. For doing every activity there are methods – How to do the activity. For example – Requirements gathering is an activity or KPA . You can gather requirement by different methods e.g. group interview , personal interview , questionnaire (printed – Web) , descriptive writing etc.

The third layer is that of tools. They provide automated or semi-automated support for the process and methods. One of the activities is Analysis and design. Methods are DFD and ERD. There are tools available which help you in preparing them and even generate code. They are called tools. CASE tools (Computer Aided Software Engineering tools)

1.4 The Software Process



Software is a product. In order to manufacture any product you have to go through a series of predictable steps/ activities. The set of steps along with their sequence is called a process. For example , in order to make a wooden table a carpenter has to follow certain steps – make legs , make top , make the connecting pieces , connect legs , fix top on the base etc. This is called manufacturing process (cooking process). Similarly, since software is a product, you have to follow a software process.

The parties involved in the software process are

The software engineers and their managers

1. The people who want or have requested the product. The important party is the user or the customer. The software is being developed for his/her use/satisfaction. Customer is the king.

The steps or the process depends on number of factors (like type of application – aircraft avionics or a college web site) and hence there are number of different options available. They are called models.

A well defined process is a must to provide stability, control and organization otherwise it can become chaotic. For example , when a house is built first civil work is completed and then electrical , plumbing and interior design work is taken up.

The software process can also be looked at in terms of a process framework (structure, skeleton) consisting of main framework activities and umbrella activities. (For example - skeleton of a building. You may have different numbers of flats/ offices with different sizes etc with some common facilities like Lift, staircase, parking, garden etc.)

The main framework activities are communication, planning, modeling, construction and deployment. These main framework activities will be applicable to all projects in varying degrees.

Communication : With customer and other stakeholders – stakeholder is someone who has a stake (interest) in the successful outcome of the project – managers, end users, software engineers, support persons. Absolutely must to understand the stakeholder’s objectives.

Planning : Plan is a map. It helps in a complex journey. Software project plan describes the technical tasks to be conducted (analysis, design, coding, testing, review etc), risk management, resource and schedule details etc.

Modeling : Create models to understand more and more details and how components interact. Data model (ERD), Functional model (DFD), or UML diagrams – class, use case, sequence, activity, component, deployment.



Construction : this activity combines Code generation and testing that is required to uncover errors in the code.

Deployment : The software (as a complete entity or as a partially completed increment) is delivered to the customer who evaluates the delivered product and provides feedback based on the evaluation.

Then there are umbrella activities – applied throughout the s/w process , covering all activities. The umbrella activities start from day one and continue till the last day. They are :

Software project tracking and control—allows the software team to assess progress against the project plan and take any necessary action to maintain the schedule.Risk management—assesses risks that may affect the outcome of the project or the quality of the product.Software quality assurance—defines and conducts the activities required to ensure software quality.Technical reviews—assesses software engineering work products in an effort to uncover and remove errors before they are propagated to the next activity.Measurement—defines and collects process, project, and product measures that assist the team in delivering software that meets stakeholders’ needs; can be used in conjunction with all other framework and umbrella activities.Software configuration management—manages the effects of change throughout the software process.Reusability management—defines criteria for work product reuse (including software components) and establishes mechanisms to achieve reusable components.Work product preparation and production—encompasses the activities required to create work products such as models, documents, logs, forms, and lists.

This process is not a rigid process to be followed for every project identically. There will be different emphasis given on different activities based on the requirements of that project. The differences can be :

1. Overall flow of activities, actions, tasks2. Degree to which actions are defined - just overall idea / minute details3. Degree to which work products are identified and required. User manual for attendance

system or library system.4. Manner in which quality assurance activities are applied – strictly. Routinely etc5. Manner in which project tracking and monitoring are applied6. Degree to which customers and other stakeholders are involved with the project. Very

less, medium, high.7. Level of autonomy (independence) given to the software team.



Chap-2 - Process Models

2.1 A Generic Process Model

A process is defined as a collection of work activities, actions and tasks that are performed when some work product is to be created. Each of these activities, actions and tasks reside within a framework (skeleton, structure) or model that defines their relationship with the process and with one another. The software process is represented schematically (graphically, diagrammatically) as follows :

There are framework activities.

Activities have actions.

Actions have tasks.

Cooking Example for preparing a vegetable dish :



Activities Actions Tasks

1. Purchase 1.1 Evaluate Vendors 1.1.1 Check General Quality of goods of vendor

1.1.2 Check Layout of vendor

1.2 Evaluate Vegetables 1.2.1 Check quality of individual vegetable

1.2.2 Ask Price of each vegetable

1.3 Select Vendor 1.3.1 Compare general quality

1.3.2 Compare general Prices

1.4 Select Vegetables

1.5 Negotiate and pay

2. Prepare 2.1 Clean 2.1.1 Separate bad material

2.1.2 Clean once

2.1.3 Clean again

2.2 Cut 2.2.1 Big pieces

2.2.2 Big to small

2.2.3 QC of cut pcs

3. Cook

4. Store

A generic process framework for software engineering defines five framework activities – Communication, Planning, modeling, Construction and Deployment. Then, there is a set of umbrella activities.

These activities have to be carried out in some sequence. That sequence is called process flow. There are different types of process flows as shown below :

a) Linear



b) Iterativec) Evolutionary and d) Parallel

2.1.1 Defining a framework Activity

For every software development project one needs to define a task set. (set of tasks required to be performed). The task set will depend on the nature of problem, the characteristics of the people doing the work and the stakeholders who are sponsoring the project.

For a small software project requested by one person (at a remote location) with simple, straightforward requirements, the communication activity might encompass little more than a phone call with the appropriate stakeholder. Therefore, the only necessary action is phone conversation, and the work tasks (the task set) that this action encompasses are:

1. Make contact with stakeholder via telephone.



2. Discuss requirements and take notes. 3. Organize notes into a brief written statement of requirements.4. E-mail to stakeholder for review and approval.

If the project was considerably more complex with many stakeholders, each with a different set of (sometime conflicting) requirements, the communication activity might have six distinct actions : inception, elicitation, elaboration,negotiation, specification, and validation. Each of these software engineering actions would have many work tasks and a number of distinct work products.

2.1.2 Identifying a Task SetEach software engineering action (e.g., elicitation, anaction associated with the communication activity) can be represented by a numberof different task sets—each a collection of software engineering work tasks, relatedwork products, quality assurance points, and project milestones. You should choosea task set that best accommodates the needs of the project and the characteristics ofyour team. This implies that a software engineering action can be adapted to the specificneeds of the software project and the characteristics of the project team.

2.1.3 process Patterns

A process pattern

describes a process-related problem that is encountered during software engineering work,

identifies the environment in which the problem has been encountered, and

suggests one or more proven solutions to the problem.

• Stated in more general terms, a process pattern provides you with a template [Amb98]—a consistent method for describing problem solutions within the context of the software process.

( defined at different levels of abstraction)

1. Problems and solutions associated with a complete process model (e.g. prototyping).

2. Problems and solutions associated with a framework activity (e.g. planning) or

3. an action with a framework activity (e.g. project estimating).

Process pattern types:



• Stage patterns—defines a problem associated with a framework activity for the process. It includes multiple task patterns as well. For example, EstablishingCommunication would incorporate the task pattern RequirementsGathering and others.

• Task patterns—defines a problem associated with a software engineering action or work task and relevant to successful software engineering practice

• Phase patterns—define the sequence of framework activities that occur with the process, even when the overall flow of activities is iterative in nature. Example includes SprialModel or Prototyping.

(see template proposed by Ambler from book Page No: 35)

2.2 Process Assessment and Improvement

The existence of a software process is no guarantee that software will be delivered on time, that it will meet the customer’s needs and that it will be of good quality (because it may not be getting done properly). The need is to get the process assessed to ensure that it is getting done correctly.

So most of the companies which develop s/w know which activities they have to carry out. But are all of them equal (TCS , Wipro , Infosys , Satyam , PCS , Contech , Applitech and other small time local companies) ? No.

WHY ? Because they are different in their capabilities.

Why do they have different capabilities? They do not do all activities like they are supposed to. Then how do you measure their capabilities? How do you assess them?

A number of different approaches to software process assessment and improvement have been proposed over the past few decades. They are

Standard CMMI Assessment Method for Process Improvement (SCAMPI) — provides a five step process assessment model that incorporates five phases: initiating, diagnosing, establishing, acting and learning.

CMM-Based Appraisal for Internal Process Improvement (CBA IPI)—provides a diagnostic technique for assessing the relative maturity of a software organization; uses the SEI CMM as the basis for the assessment [Dun01]

SPICE—The SPICE (ISO/IEC15504) standard defines a set of requirements for software process assessment. The intent of the standard is to assist organizations in developing an objective evaluation of the efficacy (effectiveness) of any defined software process. [ISO08]

ISO 9001:2000 for Software—a generic standard that applies to any organization that wants to improve the overall quality of the products, systems, or services that it provides.



Therefore, the standard is directly applicable to software organizations and companies. [Ant06]

2.3 Prescriptive Process Models

In order to transport goods and people you have number of options available regarding the type of vehicle (starting from bullock cart to bicycle, scooter , car , bus , airplane etc. ). You will require different activities, methods and tools to manufacture different vehicles. Similarly s/w also has been classified in to different categories. The steps / activities required, methods and tools will depend on the type of software. You will have choice even in generic phases also. A combination of process ,methods , tools and generic phases is called a process model or S/W engineering paradigm.

Earlier, the software development was chaos (mess, confusion, disorder). There was no software process. Software development was considered to be an art – not a science (no rules). Then, prescriptive process models were proposed to bring order to the chaos. These models are called prescriptive because they prescribe what should be done (steps to be carried out to develop software). These models brought a certain amount of useful structure to software engineering work. Some of these models are as follows :

1. Waterfall model2. Incremental Process Models3. Evolutionary process Models – Prototyping, Spiral4. Concurrent Models

(2.3.1) Waterfall model

It is the oldest paradigm for SE. When requirements are well defined and reasonably stable, it leads to a linear fashion.

It is also known as classic life cycle or linear sequential model. It suggests a systematic, sequential approach.to software development that begins with customer specification of requirements and progresses through planning, modeling, construction and deployment as shown in the following figure.

All activities are done one after another only after its predecessor is over. One can not go back to previous activity. Water once poured down a staircase can not go up to the higher step.



Communication Planning

ModelingConstruction

Deployment analysis design code

test

project initiation requirement gathering estimating

scheduling tracking

delivery support feedback

Following assumptions (problems) are made in this model

a. The user must give his / her complete requirements in advance and in detail. This is difficult in real life.

b. Completed system will be delivered after the linear sequence is complete. Since the working version is available almost at the end of the time span the user must have lot of patience. Another problem is that a major blunder – if undetected – can be disastrous.

A variation in the representation of the waterfall model is called V - model . As shown in the following figure it depicts the relationship of quality assurance actions to the actions associated with communication, modeling and early construction activities.

As a software team moves down the left side of V, basic problem requirements are refined into progressively more detailed and technical representations of the problem and its solution.



Once code has been generated , the team moves up the right side of the V, essentially performing a series of tests (quality assurance actions) that validate each of the models created as the team moved down the left side.

In reality there is no fundamental difference between the classic life cycle and V-model.

The V-model provides a way of visualizing how verification and validation actions are applied to earlier engineering work.

(2.3.2) Incremental Process Models

There are many situations in which initial software requirements are reasonably well defined, but the overall scope of the development effort precludes a purely linear process.

In addition there may be compelling need to provide a limited set of software functionality to users quickly and then refine and expand on the functionality in later software release. In such cases, u can choose a process model that is designed to produce the software in increments.

The incremental model combines elements of linear sequential model with the iterative philosophy of prototyping. First we develop a core product and deliver it. It will have the basic functionality. We follow steps of analysis , design , development , testing. Then , based on the feedback we improve existing features and add some new features. For this also we follow the 4 basic steps.

Example : word processing software developed using the incremental paradigm might deliver basic file management, editing and document production functionality in the first increment, more sophisticated editing and document production capabilities in the second increment , spelling and grammar checking in the third increment and advanced page layout capability in the fourth increment.

It should be noted that the process flow for any increment can incorporate the prototype paradigm.

This model can be used when complete staffing is not available (or is not wanted) in the beginning. The core product can be developed by a core team and the team for the successive versions can be bigger depending on the success of the product. Focus is on delivery of an operational product.



C o m m u n i c a t i o nP l a n n i n g

M o d e l i n gC o n s t r u c t i o n

De p l o y m e n t d e l i v e ry f e e d b a c k

analys is des ign code

t es t

increment # 1

increment # 2

delivery of 1st increment

delivery of 2nd increment

delivery of nth increment

increment # n

project calendar time



De p l o y m e n t d e l i v e r y f e e d b a c k

analys is des ign code

t es t



De p l o y m e n t d e l i v e r y f e e d b a c k

analys is design code

t es t

(2.3.3) Evolutionary Process Models

1. Software system evolves over time as requirements often change as development proceeds. Thus, a straight line to a complete end product is not possible. However, a limited version must be delivered to meet competitive pressure.

2. Usually a set of core product or system requirements is well understood, but the details and extension have yet to be defined.

3. You need a process model that has been explicitly designed to accommodate a product that evolved over time.

4. It is iterative that enables you to develop increasingly more complete version of the software. 5. Two types are introduced, namely Prototyping and Spiral models.

1. Prototyping model

It starts with requirements gathering. Overall objectives are defined, known requirements are identified , area where further details are required are identified and a quick design is done. The main focus is on understanding user inputs and outputs. A prototype (example , sample , model ,trial product) is prepared , evaluated by the customer and changes are suggested. This process is done in number of iterations so as to define the requirements. Ideally the prototype



should be discarded once the requirements are clear. Because the main objective of this model is to understand the user requirements clearly and then develop the actual software. In that process the s/w developer might have made some compromises regarding quality, performance and maintainability. ( Instead of using Oracle / SQL server we might have used MS Access as database – which may not be ideal for the real application or used not so efficient algorithm to show only functionality). Therefore , the rules of the game should be made clear to the customer in the beginning when you go for prototyping model. The idea is to get the requirements and even though the s/w may appear to be ideal it will be discarded once it serves its purpose.

Both stakeholders and software engineers like the prototyping paradigm. Users get a feel for the actual system, and developers get to build something immediately.

Yet prototyping can be problematic for the following reasons:

1. Stakeholders see what appears to be a working version of the software, unaware that the prototype is held together haphazardly, unaware that in the rush to get it working you haven’t considered overall software quality or long-term maintainability. When informed that the product must be rebuilt so that high levels of quality can be maintained, stakeholders cry foul and demand that “a few fixes” be applied to make the prototype a working product. Too often, software development management relents.

2. As a software engineer, you often make implementation compromises in order to get a prototype working quickly. An inappropriate operating system or programming language may be used simply because it is available and known; an inefficient algorithm may be implemented simply to demonstrate capability. After a time, you may become comfortable with these choices and forget all the reasons why they were inappropriate.



The less-than-ideal choice has now become an integral part of the system.

Communication

Quick plan

Construction of prototype

Modeling Quick design

Delivery & Feedback

Deployment

communication

Quickplan

ModelingQuick design

Constructionof prototype

Deploymentdelivery &feedback

2. The Spiral Model Originally proposed by Barry Boehm.

It couples the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model and is a risk-driven process model generator that is used to guide multi-stakeholder concurrent engineering of software intensive systems.

Two main distinguishing features: one is cyclic approach for incrementally growing a system’s degree of definition and implementation while decreasing its degree of risk. The other is a set of anchor point milestones for ensuring stakeholder commitment to feasible and mutually satisfactory system solutions.

A series of evolutionary releases are delivered. During the early iterations, the release might be a model or prototype. During later iterations, increasingly more complete version of the engineered system are produced.

The first circuit in the clockwise direction might result in the product specification; subsequent passes around the spiral might be used to develop a prototype and then progressively more sophisticated versions of the software. Each pass results in adjustments to the project plan. Cost and schedule are adjusted based on feedback. Also, the number of iterations will be adjusted by project manager.



Good to develop large-scale system as software evolves as the process progresses and risk should be understood and propdifficult to convince customers that it is controllable as it demands considerable risk assessment expertise. erly reacted to. Prototyping is used to reduce risk.

OR

This model is useful for large scale systems (like development of OS). It is evolutionary model (monkey man) like incremental model. It was proposed by Barry Boehm. This model also combines iterative approach of prototyping model with systematic approach of the linear sequential model. It is divided into 5 task regions each region consisting of a task set.

1. Customer Communication : Tasks required to establish effective communication between developer and customer

2. Planning : Tasks required to define resources , timelines , other project related information.

3. Modeling : Tasks required to build one or more representations of the application.4. Construction and release : Tasks required to construct , test ,install , and provide user

support (documentation and training)5. Deployment : Tasks required to obtain customer feedback

These task regions are performed for each stage of development e.g. concept development (product specs) , new development project , product enhancement , product maintenance. Iteration is there at every stage of product development. This model more realistically reflects the real world but still is not widely used. Development of OS.



communication

planning

modeling

constructiondeployment delivery feedback

start

analysis design

code test

estimation scheduling risk analysis

(2.3.4) The concurrent development model

• Allow a software team to represent iterative and concurrent elements of any of the process models. For example, the modeling activity defined for the spiral model is accomplished by invoking one or more of the following actions: prototyping, analysis and design.

• The Figure shows modeling may be in any one of the states at any given time. For example, communication activity has completed its first iteration and in the awaiting changes state. The modeling activity was in inactive state, now makes a transition into the under development state. If customer indicates changes in requirements, the modeling activity moves from the under development state into the awaiting changes state.

• Concurrent modeling is applicable to all types of software development and provides an accurate picture of the current state of a project. Rather than confining software engineering activities, actions and tasks to a sequence of events, it defines a process network. Each activity, action or task on the network exists simultaneously with other activities, actions or tasks. Events generated at one point trigger transitions among the states.



Under review

Baselined

Done

Underrevision

Awaitingchanges

Underdevelopment

none

Modeling activity

represents the stateof a software engineeringactivity or task

(2.3.5) A final word on evolutionary processes

( Three Concerns on Evolutionary Processes)

First concern is that prototyping poses a problem to project planning because of the uncertain number of cycles required to construct the product.

Second, it does not establish the maximum speed of the evolution. If the evolution occur too fast, without a period of relaxation, it is certain that the process will fall into chaos. On the other hand if the speed is too slow then productivity could be affected.

Third, software processes should be focused on flexibility and extensibility rather than on high quality. We should prioritize the speed of the development over zero defects. Extending the development in order to reach high quality could result in a late delivery of the product when the opportunity niche has disappeared.



Chap-3 -Agile Development

(3.1) WHAT IS AGILITY? (3.1 not in syllabus)

Just what is agility in the context of software engineering work? Ivar Jacobson provides a useful discussion:

Agility has become today's buzzword when describing a modem software process. Everyone is agile. An agile team is a nimble (quick) team able to appropriately respond to changes. Change is what software development is very much about. Changes in the software being built, changes to the team members, changes because of new technology, changes of all kinds that may have an impact on the product they build or the project that creates the product. Support for changes should be built-in everything we do in software, something we embrace because it is the heart and soul of software. An agile team recognizes that software is developed by individuals working in teams and that the skills of these people, their ability to collaborate is at the core for the success of the project.

In Jacobson's view, the pervasiveness (frequency) of change is the primary driver for agility. Software engineers must be quick on their feet if they are to accommodate the rapid changes that Jacobson describes.

But agility is more than an effective response to change. It also encompasses the philosophy espoused in the manifesto noted at the beginning of this chapter. It encourages team structures and attitudes that make communication (among team members, between technologists and business people, between software engineers and their managers) more facile. It emphasizes rapid delivery of operational software and de-emphasizes the importance of intermediate work products (not always a good thing); it adopts the customer as part of the development team and works to eliminate the "us and them" attitude that continues to pervade many software projects; it recognizes that planning in an uncertain world has its limits and that a project plan must be flexible.

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 emphasize an incremental delivery strategy that gets working software to the customer as rapidly as feasible for the product type and operational environment.



(3.3) WHAT IS AN AGILE PROCESS ?

Following are the key assumptions about the majority of software projects :

1. 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.

2. For many types of software, design and construction are interleaved. That is, both activities should be performed in tandem so that design models are proven as they are created. It is difficult to predict how much design is necessary before construction is used to prove the design.

3. Analysis, design, construction, and testing are not as predictable (from a planning point of view) as we might like.

Given these three assumptions, an important question arises: How do we create a process that can manage unpredictabi1iy? The answer lies in process adaptability (to rapidly changing project and technical conditions). An agile process, therefore, must be adaptable. Adjustable, flexible.

But continual adaptation without forward progress accomplishes little. Therefore, an agile software process must adapt incrementally. To accomplish incremental adaptation, an agile team requires customer feedback (so that the appropriate adaptations can be made). An effective catalyst for customer feedback is an operational prototype or a portion of an operational system. Hence, an incremental development strategy should be instituted. Software increments (executable prototypes or portions of an operational system) must be delivered in short time periods so that adaptation keeps pace with change (unpredictability). This iterative approach enables the customer to evaluate the software increment regularly, provide necessary feedback to the software team, and influence the process adaptations that are made to accommodate the feedback.

(3.3.1) Agility Principles

The Agile Alliance defines 12 agility principles for those who want to achieve agility:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.This is where it differs from conventional approach.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.



4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity—the art of maximizing the amount of work not done—is essential.

11. The best architectures, requirements, and designs emerge from self- organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Not every agile process model applies these 12 principles with equal weight, and some models choose to ignore (or at least downplay) the importance of one or more of the principles.

(3.3.2) The Politics of Agile Development

There is considerable debate (sometimes loud, harsh) about the benefits and applicability of agile software development as opposed to more conventional software engineering processes. Jim Highsmith states the extremes when he characterizes the feeling of the pro-agility camp ("agilists"). "Traditional methodologists are a bunch of stick-in-the-muds who'd rather produce flawless documentation than a working system that meets business needs." As a counterpoint, he states the position of the traditional software engineering camp: "Lightweight, i.e. 'agile' methodologists are a bunch of glorified hackers who are going to be in for a heck of a surprise when they try to scale up their toys into enterprise-wide software."

Like all software technology arguments, this methodology debate risks degenerating into a religious war. If warfare breaks out, rational thought disappears and beliefs rather than facts guide decision making.

No one is against agility. The real question is, what is the best way to achieve it? As important, how do you build software that meets customers' needs today and exhibits the quality



characteristics that will enable it to be extended and scaled to meet customers' needs over the long term?

There are no absolute answers to either of these questions. Even within the agile school itself, there are many proposed process models each with a subtly different approach to the agility problem. Within each model there is a set of "ideas" that represent a significant departure from traditional software engineering. And yet, many agile concepts are simply adaptations of good software engineering concepts. Bottom line: there is much that can be gained by considering the best of both schools and virtually nothing to be gained by denigrating (putting down, degrading) either approach.

(3.3.3) Human Factors

Proponents of agile software development take great pains to emphasize the importance of "people factors." As Cockburn and Highsmith state, "Agile development focuses on the talents and skills of individuals, molding the process to specific people and teams." The key point in this statement is that the process molds to the needs of the people and team, not the other way around.

If members of the software team are to drive the characteristics of the process that is applied to build software, a number of key traits must exist among the people on an agile team and the team itself:

Competence. In an agile development (as well as software engineering) context, "competence" encompasses innate (inborn) talent, specific software-related skills, and overall knowledge of the process that the team has chosen to apply. Skill and knowledge of process can and should be taught to all people who serve as agile team members.

Common focus. Although members of the agile team may perform different tasks and bring different skills to the project, all should be focused on one goal—to deliver a working software increment to the customer within the time promised. To achieve this goal, the team will also focus on continual adaptations (small and large) that will make the process fit the needs of the team.

Collaboration. Software engineering (regardless of process) is about assessing, analyzing, and using information that is communicated to the software team; creating information that will help all stakeholders understand the work of the team; and building information (computer software and relevant databases) that provides business value for the customer. To accomplish these tasks, team members must collaborate—with one another and all other stakeholders.

Decision-making ability. Any good software team (including agile teams) must be allowed the freedom to control its own destiny. This implies that the team is given autonomy—decision-making authority for both technical and project issues.



Fuzzy problem-solving ability. Software managers must recognize that the agile team will continually have to deal with ambiguity and will continually be buffeted by change. In some cases, the team must accept the fact that the problem they are solving today may not be the problem that needs to be solved tomorrow. However, lessons learned from any problem-solving

activity (including those that solve the wrong problem) may be of benefit to the team later in the project.

Mutual trust and respect. The agile team must become what DeMarco and Lister call a "jelled" team. A jelled team exhibits the trust and respect that are necessary to make them "so strongly knit that the whole is greater than the sum of the parts." Synergism.

Self-organization. In the context of agile development, self-organization implies three things: (1) the agile team organizes itself for the work to be done, (2) the team organizes the process to best accommodate its local environment, (3) the team organizes the work schedule to best achieve delivery of the software increment. (Who will do, what and when). Self-organization has a number of technical benefits, but more importantly, it serves to improve collaboration and boost team morale. In essence, the team serves as its own management. Ken Schwaber addresses these issues when he writes: "The team selects how much work it believes it can perform within the iteration, and the team commits to the work. Nothing demotivates a team as much as someone else making commitments for it. Nothing motivates a team as much as accepting the responsibility for fulfilling commitments that it made itself.

3.4 Extreme Programming (XP)

Extreme Programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements.

Extreme programming is based on values of simplicity, communication, feedback, courage, and respect.

XP is people-oriented rather than process oriented, explicitly trying to work with human nature rather than against it.

3.4.1 XP Values

Beck defines a set of 5 values that establish a foundation for all work performed as part of XP - Communication, simplicity, Feedback, courage, and respect.

Each of these values is used as a driver for specific XP activities , actions and tasks.

Communication



In order to achieve effective communication between software engineers and other stakeholders (e.g., to establish required features and functions for the software), XP emphasizes close, yet informal (verbal) collaboration between customers and developers, the establishment of effective metaphors for communicating important concepts, continuous feedback, and the avoidance of voluminous documentation as a communication medium.

Simplicity

To achieve simplicity, XP restricts developers to design only for immediate needs,

rather than consider future needs. The intent is to create a simple design that can be

easily implemented in code). If the design must be improved, it can be refactored

at a later time.

Feedback

Feedback is derived from three sources: the implemented software itself, the customer, and other software team members. By designing and implementing an effective testing strategy , the software (via test results) provides the agile team with feedback. XP makes use of the unit test as its primary testing tactic. As each class is developed, the team develops a unit test to exercise each operation according to its specified functionality. As an increment is delivered to a customer, the user stories or use cases that are implemented by the increment are used as a basis for acceptance tests. The degree to which the software implements the output, function, and behavior of the use case is a form of feedback. Finally, as new requirements are derived as part of iterative planning, the team provides the customer with rapid feedback regarding cost and schedule impact.

Courage

Beck [Bec04a] argues that strict adherence to certain XP practices demands courage. A better word might be discipline. For example, there is often significant pressure to design for future requirements. Most software teams succumb, arguing that “designing for tomorrow” will save time and effort in the long run. An agile XP team must have the discipline (courage) to design for today, recognizing that future requirements may change dramatically, thereby demanding substantial rework of the design and implemented code.

Respect

By following each of these values, the agile team inculcates respect among it members, between other stakeholders and team members, and indirectly, for the software itself. As



they achieve successful delivery of software increments, the team develops growing respect for the XP process.

3.4.2 The XP Process

-The most widely used agile process, originally proposed by Kent Beck [BEC99]

-XP uses an object-oriented approach as its preferred development paradigm

-Defines four (4) framework activities:

– Planning

– Design

– Coding

– Testing

XP –

Planning

The planning activity (also called the planning game) begins with listening – a requirements gathering activity that enables the technical members of the XP team to understand the business



context for the software and to get a broad feel for required output and major features and functionality.

Listening leads to the creation of a set of stories (also called user stories) that describe required output , features and functionality for software to be built.

Each story is written by the customer and is placed on an index card

The customer assigns a value (i.e. a priority) to the story

Agile team assesses each story and assigns a cost

Stories are grouped to for a deliverable increment

A commitment is made on delivery date.

After the first increment “project velocity” is used to help define subsequent delivery dates for other increments

XP – Design

Follows the KIS (keep it simple) principle. A simple design is always preferred over a more complex representation.

Encourage the use of CRC (class-responsibility-collaborator) cards as an effective mechanism for thinking about the software in an object oriented context. CRC cards identify and organize the object oriented classes that are relevant to the current software increment.

For difficult design problems, suggests the creation of “spike solutions”—a design prototype.

Encourages “refactoring”—an iterative refinement of the internal program design

Design occurs both before and after coding commences

XP – Coding

Recommends the construction of a series of unit tests for each of the stories before coding commences.

Encourages “pair programming”. XP recommends that two people work together at one computer workstation to create code for a story. This provides a Mechanism for real-time problem solving and real-time quality assurance. It also keeps the developers focused on the problem at hand.

Needs continuous integration with other portions (stories) of the s/w, which provides a “smoke testing” environment.



XP – Testing

Unit tests should be implemented using a framework to make testing automated. This encourages a regression testing strategy.

Integration and validation testing can occur on a daily basis

Acceptance tests, also called customer tests, are specified by the customer and executed to assess customer visible functionality

Acceptance tests are derived from user stories

3.4.3 Industrial XP (same as book)

Joshua Kerievsky [Ker05] describes Industrial Extreme Programming (IXP) in the following manner: “IXP is an organic evolution of XP. It is imbued with XP’s minimalist, customer-centric, test-driven spirit. IXP differs most from the original XP in its greater inclusion of management, its expanded role for customers, and its upgraded technical practices.” IXP incorporates six new practices that are designed to help ensure that an XP project works successfully for significant projects within a large organization.

Readiness assessment.

Prior to the initiation of an IXP project, the organization should conduct a readiness assessment. The assessment ascertains

whether (1) an appropriate development environment exists to support IXP, (2) the team will be populated by the proper set of stakeholders, (3) the organization has a distinct quality program and supports continuous improvement, (4) the organizational culture will support the new values of an agile team, and (5) the broader project community will be populated appropriately.

Project community.

Classic XP suggests that the right people be used to populate the agile team to ensure success. The implication is that people on the team must be well-trained, adaptable and skilled, and have the proper temperament to contribute to a self-organizing team. When XP is to be applied for a significant project in a large organization, the concept of the “team” should morph into that of a community. A community may have a technologist and customers who are central to the success of a project as well as many other stakeholders (e.g., legal staff, quality auditors, manufacturing or sales types) who “are often at the periphery of an IXP project yet they may play important roles on the project” [Ker05]. In IXP, the community members and their roles should be



explicitly defined and mechanisms for communication and coordination between community members should be established.

Project chartering.

The IXP team assesses the project itself to determine whether an appropriate business justification for the project exists and whether the project will further the overall goals and objectives of the organization. Chartering also examines the context of the project to determine how it complements, extends, or replaces existing systems or processes.

Test-driven management.

An IXP project requires measurable criteria for assessing the state of the project and the progress that has been made to date. Test-driven management establishes a series of measurable “destinations” [Ker05] and then defines mechanisms for determining whether or not these destinations have been reached.

Retrospectives.

An IXP team conducts a specialized technical review after a software increment is delivered. Called a retrospective, the review examines “issues, events, and lessons-learned” [Ker05] across a software increment and/or the entire software release. The intent is to improve the IXP process.

Continuous learning.

Because learning is a vital part of continuous process improvement, members of the XP team are encouraged (and possibly, incented) to learn new methods and techniques that can lead to a higherquality product.

In addition to the six new practices discussed, IXP modifies a number of existing XP practices. Story-driven development (SDD) insists that stories for acceptance tests be written before a single line of code is generated. Domain-driven design (DDD) is an improvement on the “system metaphor” concept used in XP. DDD [Eva03] suggests the evolutionary creation of a domain model that “accurately represents how domain experts think about their subject” [Ker05]. Pairing extends the XP pairprogramming concept to include managers and other stakeholders. The intent is to improve knowledge sharing among XP team members who may not be directly involved in technical development. Iterative usability discourages front-loaded interface design in favor of usability design that evolves as software increments are delivered and users’ interaction with the software is studied.

3.4.4 The XP Debate (same as in book)



All new process models and methods spur worthwhile discussion and in some instances heated debate. Extreme Programming has done both. In an interesting book that examines the efficacy of XP, Stephens and Rosenberg [Ste03] argue that many XP practices are worthwhile, but others have been overhyped, and a few are problematic. The authors suggest that the codependent nature of XP practices are both its strength and its weakness. Because many organizations adopt only a subset of XP practices, they weaken the efficacy of the entire process. Proponents counter that XP is continuously evolving and that many of the issues raised by critics have been addressed as XP practice matures. Among the issues that continue to trouble some

critics of XP are

Requirements volatility.

Because the customer is an active member of the XP team, changes to requirements are requested informally. As a consequence, the scope of the project can change and earlier work may have to be modified to accommodate current needs. Proponents argue that this happens regardless of the process that is applied and that XP provides mechanisms for controlling scope creep.

Conflicting customer needs.

Many projects have multiple customers, each with his own set of needs. In XP, the team itself is tasked with assimilating the needs of different customers, a job that may be beyond their scope of authority.

Requirements are expressed informally.

User stories and acceptance tests are the only explicit manifestation of requirements in XP. Critics argue that a more formal model or specification is often needed to ensure that omissions,

inconsistencies, and errors are uncovered before the system is built. Proponents counter that the changing nature of requirements makes such models and specification obsolete almost as soon as they are developed.

Lack of formal design.

XP deemphasizes the need for architectural design and in many instances, suggests that design of all kinds should be relatively informal. Critics argue that when complex systems are built, design must be emphasized to ensure that the overall structure of the software will exhibit quality and maintainability. XP proponents suggest that the incremental nature of the XP process limits complexity (simplicity is a core value) and therefore reduces the need for extensive design.

3.5 Other agile process models



Adaptive Software Development (ASD) Dynamic Systems Development Method (DSDM) Scrum Crystal Feature Driven Development (FDD) Lean Software Development Agile Modeling (AM) Agile Unified Process (AUP)

3.5.1 Adaptive Software Development (ASD)

Adaptive Software Development(ASD) has been proposed by Jim Highsmith [Hig00] as a technique for building complex software and systems. The philosophical underpinnings of ASD focus on human collaboration and team self-organization.

Highsmith argues that an agile, adaptive development approach based on collaboration is “as much a source of order in our complex interactions as discipline and engineering.” He defines an ASD “life cycle” shown below that incorporates three phases, speculation, collaboration, and learning.

speculation



During speculation, the project is initiated and adaptive cycle planning is conducted. Adaptive cycle planning uses project initiation information—the customer’s mission statement, project constraints (e.g., delivery dates or user descriptions), and basic requirements—to define the set of release cycles (software increments) that will be required for the project.No matter how complete and farsighted the cycle plan, it will invariably change. Based on information obtained at the completion of the first cycle, the plan is reviewed and adjusted so that planned work better fits the reality in which an ASD team is working.

collaboration

Motivated people use collaboration in a way that multiplies their talent and creative output beyond their absolute numbers. This approach is a recurring theme in all agile methods. But collaboration is not easy. It encompasses communication and teamwork, but it also emphasizes individualism, because individual creativity plays an important role in collaborative thinking. It is, above all, a matter of trust. People working together must trust one another to

(1) criticize without animosity,

(2) assist without resentment,

(3) work as hard as or harder than they do,

(4) have the skill set to contribute to the work at hand, and

(5) communicate problems or concerns in a way that leads to effective action.

learning

As members of an ASD team begin to develop the components that are part of an adaptive cycle, the emphasis is on “learning” as much as it is on progress toward a completed cycle. In fact, Highsmith [Hig00] argues that software developers often overestimate their own understanding (of the technology, the process, and the project) and that learning will help them to improve their level of real understanding.

ASD teams learn in three ways: focus groups , technical reviews and project postmortems.

The ASD philosophy has merit regardless of the process model that is used.

ASD’s overall emphasis on the dynamics of self-organizing teams, interpersonal collaboration, and individual and team learning yield software project teams that have a much higher likelihood of success.

3.5.2 Scrum

From Book



Chapter 4 -Principles that Guide Practice

4.1 Software Engineering Knowledge

You often hear people say that software development knowledge has a 3-year half-life: half of what you need to know today will be obsolete within 3 years. (Concept comes from any radio active material having a half life). In the domain of technology-related knowledge (C, C++, JAVA, etc) that’s probably about right. But there is another kind of software development knowledge—a kind that I think of as "software engineering principles"—that does not have a three-year half-life. These software engineering principles are likely to serve a professional programmer throughout his or her career.

4.2 Core Principles

Software Engineering is guided by a collection of core principles that help in the application of meaningful software process and the execution of effective software engineering methods. There are two important aspects – process and practice. Process says “what” and practice says “how”. In addition to general core principles there are core principles applicable to process and core principles applicable to practice.

General principles

1. Provide value to end user2. Keep it simple3. Maintain the vision (of the product and the project)4. Recognize that others consume what you produce5. Be open to the future6. Plan ahead for reuse

4.2.1 Principles that Guide Process (What)

Principle #1. Be agile.

Whether the process model you choose is prescriptive or agile, the basic tenets of agile development should govern your approach.

Every aspect of the work you do should emphasize economy of action—keep your technical approach as simple as possible, keep the work products you produce as concise as possible, and make decisions locally whenever possible.

Principle #2. Focus on quality at every step.



The exit condition for every process activity, action, and task should focus on the quality of the work product that has been produced.

Principle #3. Be ready to adapt.

Process is not a religious experience and dogma (belief) has no place in it. When necessary, adapt your approach to constraints imposed by the problem, the people, and the project itself.

Principle #4. Build an effective team.

Software engineering process and practice are important, but the bottom line is people. Build a self-organizing team that has mutual trust and respect.

Principle #5. Establish mechanisms for communication and coordination.

Projects fail because important information falls into the cracks and/or stakeholders fail to coordinate their efforts to create a successful end product.

Principle #6. Manage change.

The approach may be either formal or informal, but mechanisms must be established to manage the way changes are requested, assessed, approved and implemented.

Principle #7. Assess risk.

Lots of things can go wrong as software is being developed. It’s essential that you establish contingency plans.

Principle #8. Create work products that provide value for others.

Create only those work products that provide value for other process activities, actions or tasks.

4.2.2 Principles that Guide Practice (How)

These principles have merit regardless of the analysis and design methods that you apply, the construction techniques (e.g. programming languages, automated tools) that you use or the verification and validation approach that you choose.

Principle #1. Divide and conquer.

Stated in a more technical manner, analysis and design should always emphasize separation of concerns (SoC). Break up a large problem in smaller parts.

Principle #2. Understand the use of abstraction.



At its core, an abstraction is a simplification of some complex element of a system used to communication meaning in a single phrase. Abstract of a paper.

Principle #3. Strive for consistency.

Whether it’s creating a requirements model, developing a software design, generating source code, or creating test cases, the principle of consistency suggests that a familiar context makes software easier to use. As an example, consider the design of a user interface for a WebApp. Consistent placement of menu options, the use of a consistent color scheme, and the consistent use of recognizable icons all help to make the interface ergonomically sound.

Principle #4. Focus on the transfer of information.

Software is about information transfer—from a database to an end user, from a legacy system to a WebApp, from an end user into a graphic user interface (GUI), from an operating system to an application, from one software component to another—the list is almost endless. In every case, information flows across an interface, and as a consequence, there are opportunities for error, or omission, or ambiguity. The implication of this principle is that you must pay special attention to the analysis, design, construction, and testing of interfaces

Principle #5. Build software that exhibits effective modularity.

Separation of concerns (Principle #1) establishes a philosophy for software. Modularity provides a mechanism for realizing the philosophy.

Principle #6. Look for patterns.

Brad Appleton suggests that: “The goal of patterns within the software community is to create a body of literature to help software developers resolve recurring problems encountered throughout all of software development.

Principle #7. When possible, represent the problem and its solution from a number of different perspectives.

When a problem and its solution are examined from a number of different perspectives, it is more likely that greater insight will be achieved and that errors and omissions will be uncovered. For example, a requirements model can be represented using a data oriented viewpoint, a function-oriented viewpoint, or a behavioral viewpoint. Each provides a different view of the problem and its requirements

Principle #8. Remember that someone will maintain the software.

Over the long term, software will be corrected as defects are uncovered, adapted as its environment changes, and enhanced as stakeholders request more capabilities. These



maintenance activities can be facilitated if solid software engineering practice is applied throughout the software process.

4.3 principles that guide each framework activity

In addition to general core principles and core principles related to process and practice, there are principles that guide each and every framework activity. There are communication principles, planning principles, modeling principles construction principles and deployment principles.

4.3.1 Communication principles

When a software is developed a lot of communication takes place between number of parties like customer, technical peers, project manager, other stake holders etc. Effective communication is one of the most challenging activities that confront a software engineer. There are 10 principles that one needs to understand and apply in order to have successful communication. They are as follows:

1. Listen 2. Prepare before you communicate3. Someone should facilitate (make easy) the activity4. Face to face communication is best5. Take notes and document decisions6. Strive for collaboration (cooperation, teamwork)7. Stay focused, modularize your discussion8. If something is unclear, draw a picture9. Move on – in agreement or in disagreement10. Negotiation is not a contest or a game – Win Win1. Listen : That is what most of the people do not do. Try to focus on the speaker’s words, rather than formulating your response to those words. Ask for clarification but without too many interruptions. 2. Prepare before you communicate Do your homework and understand the business domain jargon (terminology, slang). If you are conducting a meeting, prepare the agenda in advance. 3. Someone should Facilitate (make easy) the activity Every communication meeting should have a leader (facilitator) to keep the conversation moving in a productive direction, to mediate (reconcile, umpire) any conflict that does occur and to ensure that the other principles are followed. 4. Face to face communication is best. But it usually works better when some other representation of the relevant information is present.



For example, a participant may create a drawing or a “strawman” documentthat serves as a focus for discussion.5. Take notes and document decisions Things have a way of falling into the cracks. Someone participating in the communication should serve as a “recorder” and write down all important points and decisions.6. Strive for collaboration (partnership, teamwork). It serves to build trust amongst team members and creates a common goal for the team which ultimately leads to success.7. Stay focused. Modularize your discussion The more people involved in any communication, the more likely that discussion will bounce from one topic to the next. The facilitator should keep the conversation modular, leaving one topic only after it has been resolved. 8. If something is unclear draw a picture One picture is worth 1000 words. Verbal direction v/s map. ERD / DFD.9. (a) Once you agree to something, move on. (b) If you can’t agree to something, move

on. (c) If a feature or function is unclear and cannot be clarified at the moment, move on.

Communication activity takes time. Do not waste time. Once you agree to something move on. If you are not able to agree then accept that we do not agree and then move on rather than getting stuck on one point (agree to disagree). If something is not clear and can not be clarified at the moment move on. 10. Negotiation is not a game or a contest which one party has to win. It works best

when both the parties win. There are many instances in which you and other stakeholders must negotiate functions and features, priorities, and delivery dates. If the team has collaborated well, all parties have a common goal. Still, negotiation will demand compromise from all parties.

4.3.2 Planning Principles

The communication activity helps a software team to define its overall goals and objectives. Now, we need to do the planning, i.e. draw the roadmap to reach the goal. Plan = Roadmap.

There are different planning philosophies. There are minimalists, traditionalists and agilists. The minimalists believe that things anyway change during the course of the project and hence there is no need to do detailed planning. The traditionalists believe that more detailed the planning less likely the team will become lost. The agilists (agile = swift, active, responsive) argue that a quick planning game may be necessary, but the roadmap will emerge as the “real work” on the software begins. Both over-planning and under-planning could cause problems and hence planning should be done in moderation.

There are 10 important principles which help in the planning exercise. They are as follows:

1. Understand the scope of the project.



Plan is the roadmap. You can not draw the map if you do not know where you are going. Scope is the destination. So define scope first. Once the scope is defined you can prepare the plan.2. Involve the customer in the planning activity. Stakeholders define priorities and establish project constraints. To accommodate these realities, software engineers must often negotiate order of delivery, time lines, and other project-related issues.

3. Recognize that planning is iterative. A project plan is never engraved in stone. As work begins, it is very likely that things will change. As a consequence, the plan must be adjusted to accommodate these changes. In addition, iterative, incremental process models dictate replanning after the delivery of each software increment based on feedback received from users.4. Estimate based on what you know. The intent of estimation is to provide an indication of effort, cost, and task duration, based on the team’s current understanding of the work to be done. If information is vague or unreliable, estimates will be equally unreliable.5. Consider risk as you define the plan. Make contingency plans and adjust the plan to take care of the risks.6. Be realistic. Accept that things will go wrong, people will make mistakes, changes will occur and make plan accordingly.

7. Adjust granularity as you define plan. Granularity refers to the level of detail that is introduced as a project plan is developed. There are two related terms fine and coarse. A “fine granularity” defines tasks over a short time increments. A “coarse granularity” defines tasks over a longer period. As you move away from the current date granularity moves from fine to coarse. It is easier and necessary to plan in detail what you are going to do today and next day and next week rather than what you are going to do in the next 6 months, one year and 5 years. 8. Define how you intend to ensure quality. The plan should identify how the software team intends to ensure quality. If technical reviews are to be conducted, they should be scheduled. If pair programming is to be used during construction, it should be explicitly defined within the plan.9. Describe how you intend to accommodate change.Even the best planning can be obviated by uncontrolled change. You should identify how changes are to be accommodated as software engineering workproceeds. For example, can the customer request a change at any time? If achange is requested, is the team obliged to implement it immediately? How is the impact and cost of the change assessed?

10. Track the plan frequently and make adjustments as required. Software projects fall behind schedule one day at a time. Therefore, it makes sense to track progress on a daily basis, looking for problem areas and situations in which scheduled work



does not conform to actual work conducted. When slippage is encountered, the plan is adjusted accordingly.

4.3.3 Modeling Principles

We create models to gain a better understanding of the actual entity to be built (house, car, plane). When the entity is a physical thing we can build a model that is identical in form and shape but smaller in scale. However, when the entity is software, our model must take a different form. It must be capable of representing the information that the software transforms (data), the architecture and functions that enable the transformation to occur, the features that the users desire and the behaviour of the system as the transformation is taking place. Models must accomplish these objectives at different levels of abstraction – first depicting the software from the customer’s viewpoint and later representing the software at a more technical level.

In software engineering work, two classes of models are created : requirement (analysis) models and design models. Requirement models represent the customer requirements by depicting the software in three different domains: the information domain, the function domain and the behavioural domain. Design models represent characteristics of software that help practitioners to construct it effectively: the architecture , the user interface and component level detail . There are separate principles and concepts that guide us in analysis modeling and design modeling.

In their book on agile modeling , Scott Ambler and Ron Jeffries define a set of modeling principles that are intended for those who use the agile process model but are appropriate for all software engineers who perform modeling actions and tasks:

Principle 1. The primary goal of the software team is to build software, not create models.

Agility means getting software to the customer in the fastest possible time. Models that make this happen are worth creating, but models that slow the process down or provide little new insight should be avoided.

Principle 2. Travel light—don’t create more models than you need.

Every model that is created must be kept up-to-date as changes occur. More importantly, every new model takes time that might otherwise be spent on construction (coding and testing). Therefore, create only those models that make it easier and faster to construct the software.

Principle 3. Strive to produce the simplest model that will describe the problem or the software.

Don’t overbuild the software . By keeping models simple, the resultant software will also be simple. The result is software that is easier to integrate, easier to test, and easier to maintain (to



change). In addition, simple models are easier for members of the software team to understand and critique, resulting in an ongoing form of feedback that optimizes the end result.

Principle 4. Build models in a way that makes them amenable to change.

Assume that your models will change, but in making this assumption don’t get sloppy. For example, since requirements will change, there is a tendency to give requirements models short shrift. Why? Because you know that they’ll change anyway. The problem with this attitude is that without a reasonably complete requirements model, you’ll create a design (design model) that will invariably miss important functions and features.

Principle 5. Be able to state an explicit purpose for each model that is created. Every time you create a model, ask yourself why you’re doing so. If you can’t provide solid justification for the existence of the model, don’t spend time on it.

Principle 6. Adapt the models you develop to the system at hand.

It may be necessary to adapt model notation or rules to the application; for example, a video game application might require a different modeling technique than real-time, embedded software that controls an automobile engine.

Principle 7. Try to build useful models, but forget about building perfect models.

When building requirements and design models, a software engineer reaches a point of diminishing returns. That is, the effort required to make the model absolutely complete and internally consistent is not worth the benefits of these properties. Am I suggesting that modeling should be sloppy or low quality? The answer is “no.” But modeling should be conducted with an eye to the next software engineering steps. Iterating endlessly to make a model “perfect” does not serve the need for agility.

Principle 8. Don’t become dogmatic about the syntax of the model. If it communicates content successfully, representation is secondary.

Although everyone on a software team should try to use consistent notation during modeling, the most important characteristic of the model is to communicate information that enables the next software engineering task. If a model does this successfully, incorrect syntax can be forgiven.

Principle 9. If your instincts tell you a model isn’t right even though it seems okay on paper, you probably have reason to be concerned.

If you are an experienced software engineer, trust your instincts. Software work teaches many lessons—some of them on a subconscious level. If something tells you that a design model is doomed to fail (even though you can’t prove it explicitly), you have reason to spend additional time examining the model or developing a different one.



Principle 10. Get feedback as soon as you can.

Every model should be reviewed by members of the software team. The intent of these reviews is to provide feedback that can be used to correct modeling mistakes, change misinterpretations, and add features or functions that were inadvertently omitted

1. Requirement Modeling Principles

There are 5 such principles.

1. The information domain must be represented and understood. What is information domain? The thing that is getting processed. Normally it is data. But events are also getting processed by the software. When the software receives an alarm signal that pressure has gone above certain limit it processes that (i.e. takes action to reduce the pressure). The alarm signal is an event. (Binary data). So information domain is data plus events. Data that is being entered, the data that is being processed, the data that is being stored and the data that flows out of the system.

2. The functions that the software is to perform in order to transform information must be defined i.e. they must be understood and models must be created.

Software functions provide direct benefit to end users and also provide internal support for those features that are user visible. Some functions transform data that flow into the system. In other cases, functions effect some level of control over internal software processing or external system elements. Functions can be described at many different levels of abstraction, ranging from a general statement of purpose to a detailed description of the processing elements that must be invoked.

3. The behavior of the software (as a consequence of external events) must be represented i.e. a behavioral model must be created. How the software reacts to external stimulus and how it changes its states e.g. when command is given to print a report it goes from “waiting for command” state to “printing a report” state.

4. The models that depict information, function and behavior must be partitioned in a manner that uncovers detail in a layered (hierarchical) fashion. Requirements modeling is the first step in software engineering problem solving. It allows you to better understand the problem and establishes a basis for the solution (design). Complex problems are difficult to solve in their entirety. For this reason, you should use a divide-and-conquer strategy. A large, complex problem is divided into subproblems until each subproblem is relatively easy to understand. This concept is called partitioning or separation of concerns, and it is a key strategy in requirements modeling.



5. The Analysis process should move from essential information towards implementation detail. You should start with logical view first and then go to physical details e.g. do not start thinking about how we are going to implement any functionality. First think about which functionality is required without specifics.

2. Design Modeling Principles

The software design model is like the architect’s plan for the house. It begins by representing the totality of the thing to be built i.e three dimensional rendering of the house and then refines the thing to provide guidance for constructing each detail (plumbing, electrical wiring, air conditioning ducting etc). Similarly the design model that is created for software provides a variety of different views of the system. There are 9 principles that are useful while doing design modeling. They are as follows :

1. Design should be traceable to the analysis model The requirements model describes the information domain of the problem,user-visible functions, system behavior, and a set of requirements classesthat package business objects with the methods that service them. The design model translates this information into an architecture, a set of subsystems that implement major functions, and a set of components that are the realization of requirements classes. The elements of the design model should be traceable to the requirements model.

2. Always consider the architecture of the system to be built. Software architecture is the skeleton of the system to be built. It affects interfaces, data structures, program control flow and behavior, the manner in which testing can be conducted, the maintainability of the resultant system, and much more. For all of these reasons, design should start with architectural considerations. Only after the architecture has been establishedshould component-level issues be considered.

3. Design of data is as important as design of processing functions. Bad data design will have negative effect on all aspects of the software, not only its final performance.

4. Interfaces (both internal and external) must be designed with care.The manner in which data flows between the components of a system has much to do with processing efficiency, error propagation, and design simplicity. A well-designed interface makes integration easier and assists the tester in validating component functions.

5. User interface design should be tuned to the needs of the end-user. Theuser interface is the visible manifestation of the software. No matter howsophisticated its internal functions, no matter how comprehensive its data



structures, no matter how well designed its architecture, a poor interface design often leads to the perception that the software is “bad.”

6. Component level design should be functionally independent. Functional independence is a measure of the “single-mindedness” of asoftware component. The functionality that is delivered by a componentshould be cohesive—that is, it should focus on one and only one function orsubfunction

7. Components should be loosely coupled to one another and to the external environment. There should not be too much dependency on other components.

8. Design representations (models) should be easily understandable.The purpose of design is to communicate information to practitioners who will generate code, to those who will test the software, and to others who may maintain the software in the future. If the design is difficult to understand, it will not serve as an effective communication medium.

9. The design should be developed iteratively. With every iteration the designer should strive for greater simplicity.Like almost all creative activities, design occurs iteratively. The first iterations work to refine the design and correct errors, but later iterations should strive to make the design as simple as is possible.

If these principles are applied at the time of design the design created will exhibit both internal and external quality factors.

External quality factors are those properties of software that can be readily observed by the user (e.g. speed, reliability, correctness, usability).

Internal quality factors are of importance to software engineers. They lead to high quality design from technical point of view. To achieve internal quality factors, the designer must understand basic design concepts.

4.3.4 Construction Principles The construction activity encompasses a set of coding and testing tasks that lead to operational software that is ready for delivery to the customer or the end-user. Here, coding may mean (1) The direct (manual) creation of programming language source code, (2) the automatic generation of source code using an intermediate design-like representation of the component to be built (decision table) or (3) the automatic generation of executable code using a fourth generation programming language like Visual C++ (where you do drag and drop).



There are different levels of testing like unit testing of component, integration testing conducted as the system is constructed, validation testing that assesses whether requirements have been met and acceptance testing that is conducted by the customer. There are fundamental principles and concepts which are applicable to coding and testing. They are as follows:

1. Coding Principles and Concepts These principles are divided into 3 parts : preparation principles (things you need to understand and do before you start writing code), coding principles (things you understand and do while you are writing the code) and validation principles (things you do after coding is done).

Preparation principles. Before you write one line of code, be sure you1. Understand the problem you are trying to solve.2. Understand basic design concepts and principles.3. Pick a programming language that meets the needs of the software to be built and the

environment in which it will operate.4. Select programming environment that provides tools that will make your work easier.5. Create a set of unit tests that will be applied once the component you code is completed.

Coding Principles. As you begin writing code, be sure you1. Construct your algorithms by following structured programming practice.2. Select data structures that will meet the needs of the design.3. Understand the software architecture and create interfaces that are consistent with it.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 other local coding standards.7. Write code that is self documenting.8. Create a visual layout (indenting, spacing) that aids understanding.

Validation Principles. After you have completed the first coding pass, be sure you1. Conduct a code walkthrough when appropriate (peer review)2. Perform unit tests and correct the errors you have uncovered.3. Refactor the code. (see if it can be improved further)

2. Testing Principles

Testing is the process of executing a program with the intent of finding an error. The main objective of testing is to find errors. It is exactly the opposite of the view held by most developers that a successful test is one in which no errors are found. Our objective is to design tests that systematically uncover different classes of errors and to do so with a minimum amount of time and error. One needs to understand following five testing principles.

1. All tests should be traceable to customer requirements. The objective of software testing is to uncover errors. It follows that the most severe defects (from the customer’s point of view) are those that cause the program to fail to meet its requirements.



2. Tests should be planned long before testing begins. All tests could be and should be planned before any code has been generated.

3. The pareto principle applies to software testing. 80 % of the errors are attributable to 20 % of the components. Identify these 20 % components and do thorough testing of these components.

4. Testing should begin “in the small” and progress toward testing “in the large”. Start with individual components and then move to clusters of components (modules) and then to the whole system.

5. Exhaustive (complete, full, comprehensive) testing is not possible. The number of path permutations for even a moderately sized program is exceptionally large. For this reason, it is impossible to execute every combination of paths during testing. It is possible, however, to adequately cover program logic and to ensure that all conditions in the component-level design have been exercised.

4.3.5. Deployment Principles

Once the software has been tested properly it has to be deployed. The deployment activity consists of three actions : delivery, support and feedback.

There are following 5 principles that guide in this activity.

1. Customer expectations for the software must be managed. Too often, the customer expects more than the team has promised to deliver,and disappointment occurs immediately. This results in feedback that is notproductive and ruins team morale. In her book on managing expectations,

Naomi Karten states: “The starting point for managing expectationsis to become more conscientious about what you communicate and how.”She suggests that a software engineer must be careful about sending the customer conflicting messages (e.g., promising more than you can reasonably deliver in the time frame provided or delivering more than you promise for one software increment and then less than promised for the next).

2. A complete delivery package should be assembled and tested. All executable software, support data files, support documents must be assembled. All installation scripts and operational features should be tried in all possible computing configurations (h/w, OS, browsers, networking arrangements etc.)

3. A support regime must be established before the software is delivered. Support should be planned, support material should be prepared and appropriate record keeping mechanism should be in place.

4. Appropriate instructional materials must be provided to the end-users. The software team delivers more than the software itself.Appropriate training aids (if required) should be developed; troubleshooting



guidelines should be provided, and when necessary, a “what’s different about this software increment” description should be published

5. Buggy software should be fixed first, delivered later. It is better to deliver error free software slightly late than delivering error prone software on time.



Software Engineering

Chapter 5 Understanding Requirements

5.1 Requirement Engineering

The step we generally know as analysis is also known as Software Requirements Engineering. It is a systematic and disciplined approach to deal with requirements. It helps software engineers to better understand the problem they will work to solve. It consists of tasks that that lead to an understanding of what the business impact of software will be, what the customer wants, and how the end-users will interact with the software. In this step the system requirements and the role allocated to software are refined in detail. The software engineer and customer play an active role in this activity and the software engineer acts as interrogator, consultant, problem solver and negotiator. The activity may appear to be simple but it is not since the communication content is very high.

Requirements Engineering Tasks

The software requirements activity is accomplished through the execution of following seven distinct functions:

1. Inception2. Elicitation3. Elaboration4. Negotiation5. Specification6. Validation7. Management

Inception : (Start, beginning). How does a software project get started? Sometimes a casual discussion results into a major software development project. But, in most of the cases the software development projects begin when a business need is identified or a potential new market or service is discovered.

Elicitation : (drawing out, extracting, obtaining)

Requirements elicitation is the process of getting requirements from the customer. It appears to be simple and easy but it is not. Difficulties faced are problems of scope (boundary is ill-defined or customers give unnecessary details), problems of understanding (customers not clear about the capability of computing environment, having problem in communicating, omit information that is obvious, give conflicting requirements etc.) and problems of volatility (change).



Elaboration : (Expansion, amplification, explanation)

The information obtained from the customer during inception and elicitation is expanded and refined during elaboration. It focuses on developing a refined technical model of software functions, features and constraints. It is basically an analysis modeling action i.e. you make analysis models like ERD, DFD, STD. The end result of elaboration is an analysis model that defines the informational, functional and behavioural domain of the problem.

Negotiation :

Lot of times customers / end users ask for more than what can be given with the resources available (time, money, manpower). There may be conflicting requirements from different users also. There is a need for the negotiation process in such cases to reconcile (resolve, settle) the conflicts. Using an iterative process the requirements are eliminated, combined, and / or modified so that each party achieves some measure of satisfaction.

Specification : Whatever requirements the requirement engineer has elicited, elaborated and finalized after negotiations so far have to be put in a form which can be used by others to take the work ahead. That process is called specification process. The output of that process is called Specification. It can be a written document, a formal mathematical model, a collection of usage scenarios, a prototype or any combination of these. For large systems it is a written document combining natural language descriptions and graphical models.

It is the final work product produced by the requirements engineer. It serves as the foundation for subsequent software engineering activities like design, development, testing etc.

Validation : (Confirmation)

Lot of work products are produced as a consequence of requirements engineering. It is necessary to assess the quality of these work products. Their quality is assessed through the step of validation. It examines the specification to ensure that all requirements have been stated unambiguously (clearly), that inconsistencies, errors and omissions are detected and resolved, and that work products conform to the standards. Validation is done through FTR (formal technical review).

Requirement Management : Requirements for computer-based systems change, and the desire to change requirements persists throughout the life of the system. Requirements management is a



set of activities that help the project team identify, control, and track requirements and changes to requirements at any time as the project proceeds.Many of these activities are identical to the software configuration management (SCM).

5.2 Establishing the ground work Starting the requirements engineering process and successfully completing it is very difficult. In an ideal setting, customers and software engineers work together on the same team. In such cases, requirements engineering is simply a matter of conducting meaningful conversations with colleagues who are well-known members of the team. But reality is often quite different. Customers may be located in a different city or country, may have only a vague (unclear) idea of what is required, may have conflicting opinions about the system to be built, may have limited technical knowledge and limited time to interact with the requirements engineer. None of these things are desirable but they do exist and the engineer has to deal with it. How do you start the process in such a situation?

5.2.1 Identify the stakeholders –Anyone who benefits in a direct or indirect way from the system, business operations managers, product managers, marketing people, internal and external customers, end users, consultants, product engineers, software engineers, support and maintenance engineers, and others.Each stakeholder has a different view of the system, achieves different benefits when the system is successfully developed, and is open to different risks if the development effort should fail.Keep expanding this list and ensure that you get contribution from all of them since all of them will have different views and requirements.

5.2.2 Recognize Multiple view points. Because many different stakeholders exist, the requirements of the system will be explored from many different points of view. For example, the marketing group is interested in functions and features that will excite the potential market, making the new system easy to sell. Business managers are interested in a feature set that can be built within budget and that will be ready to meet defined market windows. End users may want features that are familiar to them and that are easy to learn and use.Software engineers may be concerned with functions that are invisible to nontechnical stakeholders but that enable an infrastructure that supports more marketable functions and features. Support engineers may focus on the maintainability of the software.The multiple view points in lot of cases will be conflicting with each other. So categorize these conflicting, multiple view points to arrive at some decision.

5.2.3 Work toward collaboration. If five stakeholders are involved in a software project, you may have five (or more) different opinions about the proper set of requirements. Try to work as a team. A team tries to achieve the



main objective by following the philosophy of give and take rather than insisting on sticking to one’s own ideas.

5.2.4 Asking the first questionsQuestions asked at the inception of the project should be “context free” The first set of context-free questions focuses on the customer and other stakeholders, the overall project goals and benefits. For example, you might ask:

Who is behind the request for this work? Who will use the solution? What will be the economic benefit? Is there another source for the solution you need?

These questions help to identify all stakeholders who will have interest in thesoftware to be built. In addition, the questions identify the measurable benefit ofa successful implementation and possible alternatives to custom software development.The next set of questions enables you to gain a better understanding of the problem and allows the customer to voice his or her perceptions about a solution:

How would you characterize “good” output that would be generated by asuccessful solution?

What problem will this solution address? Can you show or describe the environment in which the solution will be used? Will special performance issues or constraints affect the way solution is

approached?

The final set of questions focuses on the effectiveness of the communicationactivity itself. Gause and Weinberg call these “meta-questions” and proposethe following (abbreviated) list:

Are you the right person to answer these questions? Are your answers official? Are my questions relevant to the problem you have? Am I asking too many questions? Can anyone else provide additional information? Should I be asking you anything else?

These questions (and others) will help to “break the ice” and initiate the communication that is essential to successful elicitation. But a question-and-answer meeting format is not an approach that has been overwhelmingly successful. In fact, the Q&A session should be used for the first encounter only and then replaced by a requirements elicitation format that combines elements of problem solving, negotiation, and specification.

5.3 Eliciting Requirements



5.3.1 Collaborative Requirements Gathering

(from book Page No : 128)

5.3.2 Quality Function Deployment

Quality function deployment (QFD) is a quality management technique that translates the needs of the customer into technical requirements for software. QFD “concentrates on maximizing customer satisfaction from the software engineering process” To accomplish this, QFD emphasizes an understanding of what is valuable to the customer and then deploys these values throughout the engineering process.QFD identifies three types of requirements:

Normal requirements. The objectives and goals that are stated for a product or system during meetings with the customer. If these requirements are present, the customer is satisfied. Examples of normal requirements might be requested types of graphical displays, specific system functions, and defined levels of performance.

Expected requirements. These requirements are implicit to the product or system and may be so fundamental that the customer does not explicitly state them. Their absence will be a cause for significant dissatisfaction. Examples of expected requirements are: ease of human/machine interaction, overall operational correctness and reliability, and ease of software installation.

Exciting requirements.

These features go beyond the customer’s expectations and prove to be very satisfying when present. For example, software for a new mobile phone comes with standard features, but is coupled with a set of unexpected capabilities (e.g., multitouch screen, visual voice mail) thatdelight every user of the product.

Although QFD concepts can be applied across the entire software process , specific QFD techniques are applicable to the requirements elicitation activity. QFD uses 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 requirements—called the customervoice table—that is reviewed with the customer and other stakeholders. A variety ofdiagrams, matrices, and evaluation methods are then used to extract expected requirements and to attempt to derive exciting requirements.



5.3.3 Usage Scenarios

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

5.3.4 Elicitation work products.

At the end of the elicitation step there will be few work products depending on the size of the project. Some of these work products are:

A statement of need and feasibility A bounded statement of scope for the system (how many guests, how many

items and what type of service? ) A list of customers, users and other stakeholders who participated in

requirements elicitation. A description of system’s technical environment A list of requirements and constraints that apply A set of usage scenarios (withdrawal of money from ATM, opening of a new SB

account etc) Any prototypes developed to better define requirements

5.4 Developing Use-cases

A system will have number of functionalities. Those functionalities will be useful in different situations. Use-cases describe how the system will be used in a given situation. The system will be used by people or devices. They are called actors. Basically use-cases are written narratives that describe the role of an actor.

How to write a use case

Define a set of actors. Anything that communicates with the system. It is an iterative process so not all actors are defined during the first iteration. Primary actors during first iteration and secondary actors during later iterations. Secondary actors support the system so that primary actors can do their work.

Questions that should be answered by a use case are as follows :

Who is the primary actor, the secondary actor (s)? What are the actor’s goals? What preconditions should exist before the story begins? Withdraw money

– card valid, pin right. What main tasks or functions are performed by the actor?



What extensions might be considered as the story is described? Balance not enough, time out.

What variations in the actor’s interaction are possible? What system information will the actor acquire, produce, or change? Will the actor have to inform the system about changes in the external

environment? What information does the actor desire from the system? Does the actor wish to be informed about unexpected changes?

Use-case template will help you in preparing a use case.

Use Case Name Primary actor Goal in context Preconditions Trigger Scenario details Exceptions Priority When available Frequency of use Channel to actor Secondary actors Channels to secondary actors Open issues

homeowner

Arms/ disarms system

Accesses system via Internet

Reconfigures sensors and related

system features

Responds toalarm event

Encounters anerror condition

system administrator

sensors



5.5 Building the requirements model

Intent is to provide descriptions of required information, functional, and behavioral domains for computer-based systems

5.5.1 Elements of the Requirements Model

There are many different ways to look at the requirements for a computer-basedsystem. Some software people argue that it’s best to select one mode of representation (e.g., the use case) and apply it to the exclusion of all other modes. Other practitioners believe that it’s worthwhile to use a number of different modes of representation to depict the requirements model. Different modes of representation force you to consider requirements from different viewpoints—an approach that has a higher probability of uncovering omissions, inconsistencies, and ambiguity.

The specific elements of the requirements model are dictated by the analysismodeling method that is to be used. However, a set of generic elements is common to most requirements models.

Scenario-based elements. The system is described from the user’s point of view using a scenario-based approach. For example, basic use cases and their corresponding use-case diagrams (Figure 5.2) evolve into more elaborate template-based use cases. Scenario-based elements of the requirements model are often the first part of the model that is developed. As such, they serve as input for the creation of other modeling elements. Figure 5.3 depicts a UML activity diagram for eliciting requirements and representing them using use cases. Three levels of elaboration are shown, culminating in a scenario-based representation.

Class-based elements. Each usage scenario implies a set of objects that are manipulated as an actor interacts with the system. These objects are categorized into classes—a collection of things that have similar attributes and common behaviors. For example, a UML class diagram can be used to depict a Sensor class for the SafeHome security function (Figure 5.4). Note that the diagram lists the attributes of sensors (e.g.,name, type) and the operations (e.g., identify, enable) that can be applied to modify these attributes. In addition to class diagrams, other analysis modeling elements depict the manner in which classes collaborate with one another and the relationships and interactions between classes.



Behavioral elements. The behavior of a computer-based system can have a profound effect on the design that is chosen and the implementation approach that is applied. Therefore, the requirements model must provide modeling elements that depict behavior.The state diagram is one method for representing the behavior of a system by depicting its states and the events that cause the system to change state. A state is any externally observable mode of behavior. In addition, the state diagram indicates actions (e.g., process activation) taken as a consequence of a particular event.To illustrate the use of a state diagram, consider software embedded within theSafeHome control panel that is responsible for reading user input. A simplified UML state diagram is shown in Figure 5.5.In addition to behavioral representations of the system as a whole, the behaviorof individual classes can also be modeled.

Flow-oriented elements. Information is transformed as it flows through a computer-based system. The system accepts input in a variety of forms, applies functions to transform it, and produces output in a variety of forms. Input may be a control signal transmitted by a transducer, a series of numbers typed by a human operator, a packet of information transmitted on a network link, or a voluminous data file retrieved from secondary storage. The transform(s) may comprise a single logical comparison, a complex numerical algorithm, or a rule-inference approach of an expert system. Output may light a single LED or produce a 200-page report. In effect, we cancreate a flow model for any computer-based system, regardless of size and complexity.



5.4 class diagram for sensors



5.5.2 Analysis patternsAnyone who has done requirements engineering on more than a few software projects begins to notice that certain problems reoccur across all projects within a specific application domain.

These analysis patterns suggest solutions (e.g., a class, a function, a behavior) within the application domain that can be reused when modeling many applications.

Geyer-Schulz and Hahsler suggest two benefits that can be associated with the use of analysis patterns:First, analysis patterns speed up the development of abstract analysis models that capture the main requirements of the concrete problem by providing reusable analysis models with examples as well as a description of advantages and limitations.



Second, analysis patterns facilitate the transformation of the analysis model into a design model by suggesting design patterns and reliable solutions for common problems.

Analysis patterns are integrated into the analysis model by reference to the patternname. They are also stored in a repository so that requirements engineers can usesearch facilities to find and apply them. Information about an analysis pattern (andother types of patterns) is presented in a standard template

5.6 Negotiating Requirements

Once the activities of inception, elicitation and elaboration are over, the software team has a fairly good idea about the requirements of the stakeholders. But, there are conflicts between the requirements of different stake holders and between the expectations / feasibility of customers and developers. Going ahead without resolving the conflicts will lead to failure and hence it is necessary to negotiate and arrive at a win-win situation for all. Rather than a single customer communication activity following three activities are required at the beginning of each software process iteration.

1. Identification of the stakeholders for that particular system or subsystem.2. Determination of the “win conditions” of these stakeholders.3. Negotiation of the win conditions of individual stakeholders to reconcile them into

a win-win conditions for all concerned (including the software team).

5.7 Validating Requirements

As each element of the requirements model is created, it is examined for inconsistency, omissions, and ambiguity. The requirements represented by the model are prioritized by the stakeholders and grouped within requirements packages that will be implemented as software increments. A review of the requirements model addresses the following questions:

• Is each requirement consistent with the overall objectives for the system/product?

• Have all requirements been specified at the proper level of abstraction? That is, do some requirements provide a level of technical detail that is inappropriate at this stage?

• Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system?

• Is each requirement bounded and unambiguous?

• Does each requirement have attribution? That is, is a source (generally, a specific individual) noted for each requirement?

• Do any requirements conflict with other requirements?



• Is each requirement achievable in the technical environment that will house

the system or product?

• Is each requirement testable, once implemented?

• Does the requirements model properly reflect the information, function, and behavior of the system to be built?

• Has the requirements model been “partitioned” in a way that exposes progressively more detailed information about the system?

• Have requirements patterns been used to simplify the requirements model? Have all patterns been properly validated? Are all patterns consistent with customer requirements?

These and other questions should be asked and answered to ensure that the requirements model is an accurate reflection of stakeholder needs and that it provides a solid foundation for design.



Chap-8 Design Concepts

8.3 Design Concepts

8.3.1 Abstraction (idea, thought, generality)

Abstraction is one of the fundamental ways that we as humans cope up with complexity. It is the idea of looking at a problem and the solution at the highest level using general terminology and then moving down slowly towards the implementation details. The different levels at which we see the problem and solution are called different levels of abstractions. We go to different levels of abstraction by the process of refinement.

As we move through different levels of abstraction we work to create procedural and data abstractions. A procedural abstraction is a named sequence of instructions that has a specific and limited function. For example Calculate salary can be refined into get attendance data, calculate net basic, calculate net DA, calculate net HRA, calculate gross, calculate PF, calculate professional tax, calculate loan deduction, calculate total deduction, calculate net salary etc. to get a lower level of abstraction. Then each of them can (for example how to calculate net basic) be refined further to get one more lower level of abstraction.

Data abstraction is a named collection of data that describes a data object. By refining the data object we get to the lower level of data abstraction. For example when you refine a data object called door you get its attributes like door type (revolving, sliding, normal), swing direction (in ,out, both) , weight, dimensions (LWH) etc. i.e. you are going to lower level of abstraction.

8.3.2 Architecture

“The overall structure of the software and the ways in which that structure provides conceptual integrity for a system.”

Shaw and Garlan describe a set of properties that should be specified as part of an architectural design.

Structural properties. This aspect of the architectural design representation defines the components of a system (e.g., modules, objects, filters) and the manner in which those components are packaged and interact with one another. For example, objects are packaged to encapsulate both data and the processing that manipulates the data and interact via the invocation of methods

Extra-functional properties.



The architectural design description should address how the design architecture achieves requirements for performance, capacity, reliability, security, adaptability, and other system characteristics.

Families of related systems. The architectural design should draw upon repeatable patterns that are commonly encountered in the design of families of similar systems. In essence, the design should have the ability to reuse architectural building blocks.

8.3.3 Patterns

Brad Appleton defines a design pattern in the following manner: “A pattern is a named nugget of insight which conveys the essence of a proven solution to a recurring problem within a certain context amidst competing concerns” . Stated in another way, a design pattern describes a design structure that solves a particulardesign problem within a specific context and amid “forces” that may have an impact on the manner in which the pattern is applied and used.

The intent of each design pattern is to provide a description that enables a designer to determine (1) whether the pattern is applicable to the current work,(2) whether the pattern can be reused (hence, saving design time), and (3) whetherthe pattern can serve as a guide for developing a similar, but functionally or structurally different pattern

8.3.4 Separation of Concerns

Any complex problem can be more easily handled if it is subdivided into pieces that can each be solved and/or optimized independently

A concern is a feature or behavior that is specified as part of the requirements model for the software

By separating concerns into smaller, and therefore more manageable pieces, a problem takes less effort and time to solve

For two problems, p1 and p2, if the perceived complexity of p1 is greater than the perceived complexity of p2, it follows that the effort required to solve p1 is greater than the effort required to solve p2. As a general case, this result is intuitively obvious. It does take more time to solve a difficult problem.It also follows that the perceived complexity of two problems when they are combined is often greater than the sum of the perceived complexity when each is taken separately. This leads to a divide-and-conquer strategy—it’s easier to solve a complex problem when you break it into manageable pieces. This has important implications with regard to software modularity.Separation of concerns is manifested in other related design concepts : modularity, aspects, functional independence, and refinement.



8.3.5 Modularity

Modularity is the concept of breaking up a problem into separately named and addressable components (modules) that can be integrated to satisfy the problem requirement. It is always easier to solve smaller components of a problem and then integrate the components to get the solution to the problem.

If there are two problems p1 and p2 with complexity of p1 greater than that of p2 [i.e. c(p1) > c(p2)] then the effort required to solve the problem p1 will be more than that of p2 [ i.e. E(p1) > E(p2)]. If these two problems are combined to make one problem p1 + p2 then people feel that the complexity of combined problem is more than the sum of individual complexities i.e. c(p1 + p2) > c(p1) + c(p2). Hence the same rule is applied for effort requirement. E(p1 + p2) > E(p1) + E(p2).

So people like to divide the problem and then conquer it. But how much division should be there? Breaking up the problem into smaller and smaller parts will make the effort required for every part very small but the effort required to integrate the parts will start increasing as number of parts grows. There is a total cost or effort curve that can help us in deciding the ideal number of modules. X axis – no of modules. Y axis cost or effort of development and integration.

Referring to Figure 8.2, the effort (cost) to develop an individual software module does decrease as the total number of modules increases. Given the same set of requirements, more modules means smaller individual size. However, as the number of modules grows, the effort (cost) associated with integrating the modules also grows. These characteristics lead to a total cost or effort curve shown in the figure. There is a number, M, of modules that would result in minimum development cost, but we do not have the necessary sophistication to predict M with assurance.The curves shown in Figure do provide useful qualitative guidance when modularity is considered. You should modularize, but care should be taken to stay in the vicinity of M. Undermodularity or overmodularity should be avoided.



8.3.6 Information Hiding.

Means modules should be specified and designed so that information (procedure and data) contained within one module is inaccessible (not accessible, not available, hidden from) to other modules that have no need for such information. If you use the principle of information hiding then the propagation of side effects of changes / errors will be less and your software quality will be better. (Partitioning of books in the library should be such that books required for only BCA are hidden from the view of MCA students and vice versa.)

8.3.7 Functional Independence

Everybody understands the importance of modularity in general and hence tries to solve every problem by breaking it up into number of modules. A modular design reduces complexity, facilitates change and results in easier implementation by encouraging parallel development of different parts of the system. When a system is modularised the modules should be functionally independent. This functional independence can be achieved by developing modules with “single minded” function and “aversion” (dislike) to excessive interaction with other modules. In other words each module should address a specific sub-function of requirements and should have a simple interface (meaning flow of information between modules should be less).

Independent modules are easier to develop/maintain/test and error propagation is reduced. Functional independence is a key to good design and design is the key to software quality.

How do you measure functional independence? There are two qualitative criteria cohesion and coupling. Cohesion is a measure of relative functional strength of a module. Coupling is a measure of the relative interdependence among modules.Cohesion

Cohesion (unity, hanging together) is a natural extension of the information hiding concept. A cohesive module performs a single task within a software procedure, requiring little interaction with procedures being performed in other parts of a program. A cohesive module should ideally do just one thing. (Teaching team for MCA should be cohesive i.e. should not teach BCA subjects or teach at other institutions or do something else. MCA teaching team is hidden from BCA students.) Coupling

Coupling is a measure of interconnection among modules in a software structure. In software design we try for lowest possible coupling. Simple connectivity among modules results in



software that is easier to understand and less prone to a “ripple effect”, caused when errors occur at one location and propagate through a system.

8.3.8 Refinement

Refinement is the process that gives you different levels of abstractions. It is actually a process of elaboration (explanation). (Elaborate = explain, specify, develop, improve). Refinement causes the designer to elaborate on the original statement providing more and more details as each successive refinement occurs. Abstraction and refinement are complementary processes. As you do refinement you get lower level of abstraction. DFD 0,1,2,3.Abstraction and refinement are complementary concepts. Abstraction enables you to specify procedure and data internally but suppress the need for “outsiders” to have knowledge of low-level details. Refinement helps you to reveal low-level details as design progresses. Both concepts allow you to create a complete design model as the design evolves.

8.3.9 Aspects

As requirements analysis occurs, a set of “concerns” is uncovered. These concerns “include requirements, use cases, features, data structures, quality-of-service issues, variants, intellectual property boundaries, collaborations, patterns and contracts”

Ideally, a requirements model can be organized in a way that allows you to isolate each concern (requirement) so that it can be considered independently.

In practice, however, some of these concerns span the entire system and cannot be easily compartmentalized.

As design begins, requirements are refined into a modular design representation.

Consider two requirements, A and B. Requirement A crosscuts requirement B “if a

software decomposition [refinement] has been chosen in which B cannot be satisfied without taking A into account”

8.3.10 Refactoring

It is a reorganization technique that simplifies the design (or code) of a component without changing its function or behavior. Another definition is refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the component yet improves its internal working. Breaking up of a non-cohesive component into 2 or 3 cohesive parts.



8.3.11 object oriented design concept

The object-oriented (OO) paradigm is widely used in modern software engineering.

8.3.12 Design classes

The requirements model defines a set of analysis classes. Each describes some element of the problem domain, focusing on aspects of the problem that are user visible. The level of abstraction of an analysis class is relatively high.

As the design model evolves, you will define a set of design classes that refine the analysis classes by providing design detail that will enable the classes to be implemented, and implement a software infrastructure that supports the business solution.

Five different types of design classes, each representing a different layer of the design architecture, can be developed

1. User interface classes define all abstractions that are necessary for humancomputer interaction (HCI). In many cases, HCI occurs within the context of a metaphor (e.g., a checkbook, an order form, a fax machine), and the design classes for the interface may be visual representations of the elements of the metaphor.

2. Business domain classes are often refinements of the analysis classes defined earlier. The classes identify the attributes and services (methods) that are required to implement some element of the business domain.

3. Process classes implement lower-level business abstractions required to fully manage the business domain classes.

4. Persistent classes represent data stores (e.g., a database) that will persist beyond the execution of the software.

5. System classes implement software management and control functions that enable the system to operate and communicate within its computing environment and with the outside world.

Arlow and Neustadt suggest that each design class be reviewed to ensure that it is “well-formed.” They define four characteristics of a well-formed design class:

1. Complete and sufficient. A design class should be the complete encapsulation of all attributes and methods that can reasonably be expected (based on a knowledgeable interpretation of the class name) to exist for the class.

For example, the class Scene defined for video-editing software is complete only if it contains all attributes and methods that can reasonably be associated with the creation of a video scene.



Sufficiency ensures that the design class contains only those methods that are sufficient to achieve the intent of the class, no more and no less.

2. Primitiveness. Methods associated with a design class should be focused on accomplishing one service for the class. Once the service has been implemented with a method, the class should not provide another way to accomplish the same thing.

For example, the class VideoClip for video-editing software might have attributes start-point and end-point to indicate the start and end points of the clip (note that the raw video loaded into the system may be longer than the clip that is used). The methods, setStartPoint() and setEndPoint(), provide the only means for establishing start and end points for the clip.

3. High cohesion. A cohesive design class has a small, focused set of responsibilities and single-mindedly applies attributes and methods to implement those responsibilities.

For example, the class VideoClip might contain a set of methods for editing the video clip. As long as each method focuses solely on attributes associated with the video clip, cohesion is maintained.

4. Low coupling. Within the design model, it is necessary for design classes to collaborate with one another. However, collaboration should be kept to an acceptable minimum. If a design model is highly coupled (all design classes collaborate with all other design classes), the system is difficult to implement, to test, and to maintain over time. In general, design classes within a subsystem should have only limited knowledge of other classes. This restriction, called the Law of Demeter , suggests that a method should only send messages to methods in neighboring classes.

8.4 The Design Model

The design model can be viewed in two different dimensions as illustrated in the following Figure.

The process dimension indicates the evolution of the design model as design tasks are executed as part of the software process.

The abstraction dimension represents the level of detail as each element of the analysis model is transformed into a design equivalent and then refined iteratively.

Referring to Figure, the dashed line indicates the boundary between the analysis and design models.

In some cases, a clear distinction between the analysis and design models is possible.



In other cases, the analysis model slowly blends into the design and a clear distinction is less

obvious.

1. Data design elements 2. Architectural design elements 3. Interface design elements 4. Component- level design elements 5. Deployment-level design elements

(refer book for description of these elements. P.N : 234 to 238 )



Chap- 9

Architectural Design

9.1.1 What is Architecture?

What is software Architecture of a computing system? It is the structure of the system consisting of its various components, the

externally visible properties of those components and the relationships among them.

Software architecture is a representation that enables a software engineer to i. Analyze the effectiveness of the design in meeting stated requirements

ii. Consider architectural alternatives iii. Reduce the risk associated with the construction of the software iv. Examine the system as a whole

At the architectural level, internal properties like details of algorithms are not specified.

When we design the software architecture, basically we have to do data design and architectural design.

9.3 Architectural styles

When we talk of architecture of a building we can specify number of its attributes by referring to it as one of the predefined styles e.g. Chinese, Egyptian, Roman etc.Similarly software that is built for computer-based systems also exhibits one of many architectural styles. Each style describes a system category that encompasses (1) a set of components (e.g., a database, computational modules) that perform a function required by a system; (2) a set of connectors that enable “communication, coordination and cooperation” among components; (3) constraints that define how components can be integrated to form the system; and (4) semantic models that enable a designer to understand the overall properties of a system by analyzing the known properties of its constituent parts9.3.1 A Brief taxonomy of architectural styles

Out of millions of computer-based systems developed so far in the last 50 years the vast majority can be categorized into one of a relatively small number of architectural styles. They are as follows:

1. Data – centered architectures

A data-store like a file or a database resides at the center of this architecture and is accessed frequently by other components that update, delete, or otherwise modify data within the store.



The client software accesses a central repository. In some cases the data repository is passive meaning the client software accesses the data independent of any changes to the data or the actions of other client software. A variation of this approach transforms the repository into a “blackboard” that sends notifications to client software when data of interest to the client change.

This style promotes integrability i.e. existing components can be changed and new client components can be added to the architecture without concern about other clients since the client components operate independently.

2. Data-flow architecture

This architecture is applied when input data are to be transformed through a series of computational or manipulative components into output data. This style can be described as a pipe and filter pattern. Shown in the following Figure . Components are called filters. They transform data and transmit them through the pipes to the next filter. Each filter works independently of those components upstream and downstream. It expects data input in a certain form and generates output of a specified form. It does not require knowledge of the working of its neighboring filters. (Seems like assembly line. Result processing software for B Sc ?).

If the data flow degenerates into a single line of transforms, it is termed batch sequential. This pattern accepts a batch of data and then applies a series of sequential



components (filters) to transform it. (Result processing for lower standards. All students study the same subjects.)

3. Call and return architecture

When one requires flexibility to modify the program structure one can use this type of architecture. There are number of sub-styles in this type of architecture like Main program / subprogram architectures where the program structure is

decomposed into a control hierarchy i.e. a main program invokes a number of program components which in turn may invoke still other components. Shown in the following Figure . (MS Word or Excel?)

Remote procedure call architectures where the components of the main program / subprogram are distributed across multiple computers on a network.



4. Object oriented architectures

The components of a system encapsulate data and the operations that must be applied to manipulate the data. Communication and coordination between components is accomplished by message passing.

5. Layered architectures

In this architecture a number of different layers are defined, each accomplishing operations that progressively become closer to the machine instruction set, Shown in the following Figure . At the outer layer, components service user interface operations. At the inner layer, components perform operating system interfacing. Intermediate layers provide utility services and application software functions. (OS?)



9.3.2 Architectural Patterns (12.3)

9.3.3 Organization and Refinement (same as book)

(How do I assess an architectural style that has been derived?)

Because the design process often leaves you with a number of architectural alternatives, it is important to establish a set of design criteria that can be used to assess an architectural design that is derived. The following questions provide insight into an architectural style:

Control. How is control managed within the architecture? Does a distinct control hierarchy exist, and if so, what is the role of components within this control hierarchy? How do components transfer control within the system? How is control shared among components? What is the control topology (i.e., the geometric form that the control takes)? Is control synchronized or do components operate asynchronously?

Data. How are data communicated between components? Is the flow of data continuous, or are data objects passed to the system sporadically? What is the mode of data transfer (i.e., are data



passed from one component to another or are data available globally to be shared among system components)? Do data components (e.g., a blackboard or repository) exist, and if so, what istheir role? How do functional components interact with data components? Are data components passive or active (i.e., does the data component actively interact with other components in the system)? How do data and control interact within the system?

These questions provide the designer with an early assessment of design quality and lay the foundation for more detailed analysis of the architecture

9.4 Architectural Design

What do you do when you design architecture?

Software to be developed must be put into context (i.e. model external entities and define interfaces)

Identify architectural archetypes i.e. Basic types of components. (collection of abstractions that must be modeled if the system is to be constructed)

Specify structure of the system by defining and refining the software components needed to implement each archetype

Continue the process iteratively until a complete architectural structure has been derived

9.4.1 Representing the System in Context (How do systems interoperate with one another)

Use the architectural context diagram to model the manner in which the system interacts with external entities

Systems that interoperate with the target system are represented aso Superordinate systems – using the target system as part of some higher level

processing schemeo Subordinate systems – used by the target system to provide data or processing needed

to complete the target systemo Peer level systems – producing or consuming information need by peers of the target

systemo Actors – people or devices that interact with the system to produce or consume

information needed for requisite processing Interfaces must be defined All the data that flow into or out of the target system must be identified



To illustrate the use of the ACD, consider the home security function of the SafeHome product. The overall SafeHome product controller and the Internet-based system are both superordinate to the security function and are shown above the function in the following figure.

The surveillance function is a peer system and uses (is used by) the home security function in later versions of the product.

The homeowner and control panels are actors that are both producers and consumers of information used/produced by the security software.

Finally, sensors are used by the security software and are shown as subordinate to it.

target system: Security Function uses

uses peershomeowner

Safehome Product

Internet-based system

surveillance function

sensors

control panel

sensors

uses



9.4.2 Defining Archetypes Basic types of components.

Archetype is a class or pattern that represents a core abstraction critical to the design of an architecture for a core system

Archetypes are the abstract building blocks of an architectural design May be defined by examining the analysis classes defined in the analysis model Determine the stable elements of the architecture that will need to be implemented when the

system is built

For the SafeHome home security function, you might define the following archetypes:

• Node. Represents a cohesive collection of input and output elements of the home security function. For example a node might be comprised of(1) various sensors and (2) a variety of alarm (output) indicators.• Detector. An abstraction that encompasses all sensing equipment that feeds information into the target system.• Indicator. An abstraction that represents all mechanisms (e.g., alarm siren, flashing lights, bell) for indicating that an alarm condition is occurring.• Controller. An abstraction that depicts the mechanism that allows the arming or disarming of a node. If controllers reside on a network, they have the ability to communicate with one another.Each of these archetypes is depicted using UML notation as shown in the following figure.

Figure 10.7 UML relationships for SafeHome security function archetypes (adapted from [BOS00])

Controller

Node

communicates with

Detector Indicator

9.4.3 Refining Architecture into Components



Process begins with an examination of the analysis classes for entities from the business domain that must be addressed in the software architecture

Infrastructure components needed to support the business functions but have no business connection to the application domain

The interfaces depicted in the architecture context diagram may imply specialized components needed to process data that crosses the interfaces

Look for archetypes that are reoccur in several components and create new components that service each repeating design pattern

UML component diagrams are used to represent the overall architectural structure

For SafeHome home security function example, we might define the set of top-level components that address the following functionality:

• External communication management—coordinates communication of the security function with external entities such as other Internet-based systems and external alarm notification.

• Control panel processing—manages all control panel functionality.

• Detector management—coordinates access to all detectors attached to the system.

• Alarm processing—verifies and acts on all alarm conditions.

The overall architectural structure (represented as a UML component diagram) is illustrated in the following figure.

Transactions are acquired by external communication management as they move in from components that process the SafeHome GUI and the Internet interface. This information is managed by a SafeHome executive component that selects the appropriate product function (in this case security). The control panel processing component interacts with the homeowner to arm/disarm the security function. The detector management component polls sensors to detect an alarm condition, and the alarm processing component produces output when an

alarm is detected.



SafeHome Executive

External Communication Management

GUI Internet Interface

Function selection

Security Surveillance Home management

Control panel

processing

detector management

alarm processing

Describing Instantiations of the System

The architectural design that has been modeled to this point is still relatively high level. The context of the system has been represented, archetypes that indicate the important abstractions within the problem domain have been defined, the overall structure of the system is apparent, and the major software components have been identified. However, further refinement is still necessary.

Following figure illustrates an instantiation of the SafeHome architecture for the security

system. Top level Components are elaborated to show additional detail.

For example, the detector management component interacts with a scheduler infrastructure component that implements polling of each sensor object used by the security system. Similar elaboration is performed for each of the top level components.



9.5 Assessing alternative architectural designs

The architectural style would depend on the requirements. It is possible to combine different styles and derive a new design that best fits the requirements. There may be number of alternatives which may fit the requirements. Then you have to assess different alternatives by asking questions regarding data and controls. This will give preliminary idea regarding the quality of design. But you need to do a detailed assessment of the quality of design of different alternatives. One of the approaches available is called ATAM. An architectural trade-off analysis method. This approach has been developed by Software Engineering Institute. It is called Architecture Trade-off Analysis Method (ATAM). It is an iterative process and you have to perform the required activities in sequence.

9.5.1 An Architecture Trade-Off Analysis Method

The Software Engineering Institute (SEI) has developed an architecture trade-off analysis method (ATAM) that establishes an iterative evaluation process for software architectures. The design analysis activities that follow are performed iteratively:



1. Collect scenarios. A set of use cases (Chapters 5 and 6) is developed to represent the system from the user’s point of view.

2. Elicit requirements, constraints, and environment description. This information is determined as part of requirements engineering and is used to be certain that all stakeholder concerns have been addressed.

3. Describe the architectural styles/patterns that have been chosen to address the scenarios and requirements. The architectural style(s) should be described using one of the following architectural views:

• Module view for analysis of work assignments with components and the

degree to which information hiding has been achieved.

• Process view for analysis of system performance.

• Data flow view for analysis of the degree to which the architecture meets functional requirements.

4. Evaluate quality attributes by considering each attribute in isolation. The number of quality attributes chosen for analysis is a function of the time available for review and the degree to which quality attributes are relevant to the system at hand. Quality attributes for architectural design assessment include reliability, performance, security, maintainability, flexibility, testability, portability, reusability, and interoperability.

5. Identify the sensitivity of quality attributes to various architectural attributes for a specific architectural style. This can be accomplished by making small changes in the architecture and determining how sensitive a quality attribute, say performance, is to the change. Any attributes that are significantly affected by variation in the architecture are termed sensitivity points.

6. Critique candidate architectures (developed in step 3) using the sensitivity analysis conducted in step 5. The SEI describes this approach in the following

manner :

Once the architectural sensitivity points have been determined, finding trade-off points is simply the identification of architectural elements to which multiple attributes are sensitive. For example, the performance of a client-server architecture might be highly sensitive to the number of servers (performance increases, within some range, by increasing the number of servers). . . . The number of servers, then, is a trade-off point with respect to this architecture.



These six steps represent the first ATAM iteration. Based on the results of steps 5 and 6, some architecture alternatives may be eliminated, one or more of the remaining architectures may be modified and represented in more detail, and then the ATAM steps are reapplied

9.5.2 Architectural Complexity

One should assess any proposed architecture for complexity also. Lower the complexity, better the architecture. The technique used for assessing complexity considers dependencies between

components. There can be three types of dependencies:

Sharing dependencies

Sharing dependencies represent dependence relationships among consumers who use the same resource or producers who produce for the same consumers.

For example, for two components u and v, if u and v refer to the same global data, then there exists a shared dependence relationship between u and v.

Flow dependencies

Flow dependencies represent dependence relationships between producers and consumers of resources.

For example, for two components u and v, if u must complete before control flows into v (prerequisite), or if u communicates with v by parameters, then there exists a flow dependence relationship between u and v.

Constrained dependencies

Constrained dependencies represent constraints on the relative flow of control among a set of activities. For example, for two components u and v, u and v cannot execute at the same time (mutual exclusion), then there exists a constrained dependence relationship between u and v.

9.5.3 Architectural Description Language (ADL)

One needs a language to describe anything. There is a special language to describe the architecture of software systems. It is called ADL.



Architectural description language (ADL) provides a semantics and syntax for describing a software architecture

Provide the designer with the ability to: decompose architectural components compose individual components into larger architectural blocks and represent interfaces (connection mechanisms) between components.

Once descriptive, languagebased techniques for architectural design have been established, it is more likely that effective assessment methods for architectures will be established as the design evolves.
