Software Engineering - Tamilnadu · Concepts of requirements engineering and Analysis ... Roger S. Pressman, “Software Engineering ... The purpose of this chapter is to provide

CS6403 SOFTWARE ENGINEERING

1SCE DEPARTMENT OF CSE

A Course Material on

Software Engineering

By

Mr. Ramkumar.C

ASSISTANT PROFESSOR

DEPARTMENT OF COMPUTER AND ENGINEERING

SASURIE COLLEGE OF ENGINEERING

VIJAYAMANGALAM – 638 056



QUALITY CERTIFICATE

This is to certify that the e-course material

Subject Code : CS6403

Scubject : Software Engineering

Class : II Year CSE

being prepared by me and it meets the knowledge requirement of the university curriculum.

Signature of the Author

Name: C.RAMKUMAR

Designation: ASSISTANT PROFESSOR

This is to certify that the course material being prepared by Mr.C.Ramkumar is of adequatequality. She has referred more than five books among them minimum one is from abroad author.

Signature of HD

Name: P.MURUGAPRIYA

SEAL



TABLE OF CONTENTSS.NO DATE TOPIC PAGE NO

UNIT-I SOFTWARE PROCESS AND PROJECT MANAGEMENT1 Introduction to Software Engineering 52 Software Process, Perspective and Specialized Process

Models6

3 Software Project Management: Estimation 9

4 LOC and FP Based Estimation, COCOMO Model 105 Project Scheduling – Scheduling, Earned Value

Analysis - Risk Management.19

UNIT-II REQUIREMENTS ANALYSIS AND SPECIFICATION6 Software Requirements: Functional and Non-

Functional, User requirements, System requirements,Software Requirements Document

22

7 Requirement Engineering Process: Feasibility Studies,Requirements elicitation and analysis

24

8 requirements validation, requirements management 289 Classical analysis 3010 Structured system Analysis 3111 Petri Nets-Data Dictionary 32

UNIT-III SOFTWARE DESIGN12 Design process 3413 Design Concepts-Design Model 3514 Design Heuristic 3515 Architectural Design 3816 Architectural styles, Architectural Design,

Architectural Mapping using Data Flow39

17 User Interface Design 4218 Interface analysis, Interface Design 4319 Component level Design 4420 Designing Class based components, traditional

Components44

UNIT-IV TESTING AND IMPLEMENTATION21 Software testing fundamentals 4622 Internal and external views of Testing 4723 white box testing-basis path testing 4824 control structure testing 4825 black box testing 5026 Regression Testing 5127 Unit Testing 5228 Integration Testing 5329 Validation Testing 54



30 System Testing And Debugging 5631 Software Implementation Techniques: Coding

practices57

32 Refactoring 57UNIT-V PROJECT MANAGEMENT

33 Estimation – FP Based, LOC Based, Make/BuyDecision, COCOMO II

59

34 Planning – Project Plan, Planning Process, RFP RiskManagement

62

35 Identification, Projection, RMMM 6436 Scheduling and Tracking 7337 Relationship between people and effort, Task Set &

Network, Scheduling, EVA76

38 Process and Project Metrics 77APPENDICES

A Glossary 79

B Question Bank 89

C Previous Year University question papers 107



CS6403 SOFTWARE ENGINEERING L T P C3 0 0 3

OBJECTIVES:The student should be made to:

Understand the phases in a software projectUnderstand fundamental concepts of requirements engineering and Analysis Modelling.Understand the major considerations for enterprise integration and deployment. Learn

various testing and maintenance measures

UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT 9Introduction to Software Engineering, Software Process, Perspective and Specialized ProcessModels – Software Project Management: Estimation – LOC and FP Based Estimation, COCOMOModel – Project Scheduling – Scheduling, Earned Value Analysis - Risk Management.

UNIT II REQUIREMENTS ANALYSIS AND SPECIFICATION 9Software Requirements: Functional and Non-Functional, User requirements, System requirements,Software Requirements Document – Requirement Engineering Process: Feasibility Studies,Requirements elicitation and analysis, requirements validation, requirements management-Classicalanalysis: Structured system Analysis, Petri Nets-Data Dictionary.

UNIT III SOFTWARE DESIGN 9Design process – Design Concepts-Design Model– Design Heuristic – Architectural Design –Architectural styles, Architectural Design, Architectural Mapping using Data Flow- User InterfaceDesign: Interface analysis, Interface Design –Component level Design: Designing Class basedcomponents, traditional Components.

UNIT IV TESTING AND IMPLEMENTATION 9Software testing fundamentals-Internal and external views of Testing-white box testing-basis pathtesting-control structure testing-black box testing- Regression Testing – Unit Testing – IntegrationTesting – Validation Testing – System Testing And Debugging – Software ImplementationTechniques: Coding practices-Refactoring.

UNIT V PROJECT MANAGEMENT 9Estimation – FP Based, LOC Based, Make/Buy Decision, COCOMO II - Planning – Project Plan,Planning Process, RFP Risk Management – Identification, Projection, RMMM - Scheduling andTracking –Relationship between people and effort, Task Set & Network, Scheduling, EVA –Process and Project Metrics.

TOTAL: 45 PERIODSOUTCOMES:At the end of the course, the student should be able to

Identify the key activities in managing a software project. Compare different processmodels.

Concepts of requirements engineering and Analysis Modeling.Apply systematic procedure for software design and deployment. Compare and contrast the

various testing and maintenance.TEXT BOOK:

1. Roger S. Pressman, “Software Engineering – A Practitioner’s Approach”, Seventh Edition, McGraw-Hill International Edition, 2010.



REFERENCES:1. Ian Sommerville, “Software Engineering”, 9th Edition, Pearson Education Asia, 2011.

2. Rajib Mall, “Fundamentals of Software Engineering”, Third Edition, PHI Learning PrivateLimited ,2009.

3. Pankaj Jalote, “Software Engineering, A Precise Approach”, Wiley India, 2010.

4. Kelkar S.A., “Software Engineering”, Prentice Hall of India Pvt Ltd, 2007.

5. Stephen R.Schach, “Software Engineering”, Tata McGraw-Hill Publishing Company Limited,2007.

.



UNITI SOFTWARE PROCESS AND PROJECT MANAGEMENT 9Introduction to Software Engineering, Software Process, Perspective and Specialized Process Models –Software Project Management: Estimation – LOC and FP Based Estimation, COCOMO Model – ProjectScheduling – Scheduling, Earned Value Analysis - Risk Management.

1.1.1 Introduction to Software Engineering:

In order to organize and manage a software development project successfully, one must combinespecific knowledge, skills, efforts, experience, capabilities, and even intuition. They are all necessary inorder to be able answer questions such as: What artifacts to manage and control during softwaredevelopment? How to organize the development team? What are the indicators and measures of theproduct's quality? How to employ a certain set of development practices? How to transition a softwaredevelopment organization to a new modeling and/or development paradigm? How to create and maintaina good relationship with the customers and end-users? What remedial actions to take when somethinggoes wrong in the course of the project? What are the heuristics that can help managers in conducting thesoftware development process

The manager of a software development project should answer the above questions in the contextof the project itself. However, there is a vast amount of knowledge the manager should possess thattranscends the boundaries of any specific project.

The purpose of this chapter is to provide an extended overview of many important issues aroundwhich such knowledge should be structured. The introductory section merely introduces the issues andthe context within which the other sections discuss them. Each of the remaining sections covers one of theissues in more detail. The idea has been to provide a balanced coverage of the issues from both themanager's and the developer's perspectives.

Software development is a complex process involving such activities as domain analysis,requirements specification, communication with the customers and end-users, designing and producingdifferent artifacts, adopting new paradigms and technologies, evaluating and testing software products,installing and maintaining the application at the end-user's site, providing customer support, organizingend-user's training, envisioning potential upgrades and negotiating about them with the customers, andmany more.

In order to keep everything under control, eliminate delays, always stay within the budget, andprevent project runaways, i.e. situations in which cost and time exceed what was planned, softwareproject managers must exercise control and guidance over the development team throughout the project'slifecycle. In doing so, they apply a number of tools of both economic and managerial nature. The firstcategory of tools includes budgeting, periodic budget monitoring, user chargeback mechanism,continuous cost/benefit analysis, and budget deviation analysis. The managerial toolbox includes bothlong-range and short-term planning, schedule monitoring, feasibility analysis, software quality assurance,organizing project steering committees, and the like.



Software Software Requirements

DevelopmentArchitecture Engineering

ProcessOrganizational Software

Aspects

Management Software SoftwareStrategiesand Project Quality

Strategiesand Project

QualityAssurance

Techniques ManagementProductivity

Risk

RiskAssessment

StandardsSoftware

Software

Best PracticesMetrics

ConfigurationManagement

Figure 1 - Some important issues of software project management

All of these activities and tools help manage a number of important issues in the process of softwaredevelopment. Figure 1 illustrates some of the issues, but definitely not all of them. The issues shown inFigure 1 have been selected for an extended overview in the remainder of this chapter based on thefollowing criteria:

their priority in the concerns of most software project managers, according to the managersthemselves - this is evident from the case studies, interviews, and reports of many software projectmanagers and consultants in software industry worldwide (see, for example, [12], [20], and [49]);their importance as identified by relevant committees, associations, and consortia of software developers(see, for example, [26]).

The chapter does not address the economic aspects of software project management, such asbudgeting, negotiating, outsourcing, and contracts. The goal is to consider some of the importantmanagerial issues specific to software development, not those that appear in other kinds of developmentprojects as well.

1.1.2 Software Process, Perspective and Specialized Process Models:

One of the primary duties of the manager of a software development project is to ensure that allof the project activities follow a certain predefined process, i.e. that the activities are organized as a seriesof actions conducing to a desirable end [33]. The activities are usually organized in distinct phases, andthe process specifies what artifacts should be developed and delivered in each phase. For a softwaredevelopment team, conforming to a certain process means complying with an appropriate order of actions



or operations. For the project manager, the process provides means for control and guidance of theindividual team members and the team as a whole, as it offers criteria for tracing and evaluation of theproject's deliverables and activities.

Software development process encompasses many different tasks, such as domain analysis anddevelopment planning, requirements specification, software design, implementation and testing, as wellas software maintenance. Hence it is no surprise at all that a number of software development processesexist. Generally, processes vary with the project’s goals (such as time to market, minimum cost, higherquality and customer satisfaction), available resources (e.g., the company’s size, the number, knowledge,and experience of people -- both engineers and support personnel -- and hardware resources), andapplication domain.

However, every software developer and manager should note that processes are very important. It isabsolutely necessary to follow a certain predefined process in software development. It helps developersunderstand, evaluate, control, learn, communicate, improve, predict, and certify their work. Sinceprocesses vary with the project's size, goals, and resources, as well as the level at which they are applied(e.g., the organization level, the team level, or the individual level), it is always important to define,measure, analyze, assess, compare, document, and change different processes.

There are several well-known examples of software development processes. Each process relies on acertain model of software development. The first well-established and well-documented softwaredevelopment process has followed the waterfall model. One of its variants is shown in Figure 2. Themodel assume that the process of software development proceeds through several phases in a more-or-less linear manner. The phases indicated in Figure 2 are supposed to be relatively independent. There isnot much feedback and returning to previous phases other than the one directly preceding the phase infocus. In other words, once a certain phase is finished it is considered closed, and the work proceeds withthe next phase. Many developers have criticized the waterfall model for its rigidity in that sense, and forits failure to comply with the reality of ever-changing requirements and technology. However, thewaterfall model is at least partially present in most of the other models as well, simply because of itsnatural order of phases in software development.

System feasibility

Requirements specification

Preliminary designDetailed design Module

coding and testing

System integrationSystem testing

Maintenance

Figure 2 - The waterfall model of software development

There have been many attempts to overcome the limitations of the waterfall model. Two commonpoints in all such attempts are introduction of iterations in software development activities andincremental development. Iterative and incremental software development means going through the sameactivities more than once, throughout the product's lifecycle, each time producing new deliverables and/orimproving the old ones. The main advantage of working in that way is that each individual developerworks on a small ``work packet" at any given moment, which is much easier to control.

A classical example of iterative and incremental models is the spiral model [9], sketched in Figure 3.In the spiral model, there are five core tasks: planning and design (largely corresponding to the classicalanalysis phase), approval (requirements specification), realization (design and implementation), revision(testing and modification), and evaluation (integration and system-level testing). The process iterates



through these tasks, getting closer and closer to the end by adding increments (e.g., new functions, newdesign, new modules, new or improved testing procedures, new or improved parts of the user interface,new integration and testing certificates, and so on) to the product in each iteration. The spiral modelunderlies many processes, such as DBWA (Design By

5Walking Around) [50], and PADRE (Plan-Approve-Do-Review-Evaluate) [41]. The DBWA processcombines the spiral model with multiple design views, flexible structuring of development teams, anddynamic changes in modes of working (e.g., working individually, working in pairs, or working in smallteams), in order to improve the process efficiency and parallelism. The PADRE process uses the spiralmodel at multiple levels - the project level, the phase level, and the individual software module level -thus creating the ``spiral in a spiral in a spiral" effect.

Approve

Plan

Do

Evaluate

Review and Revise

Figure 3 - The spiral model of software development (after [9] and [41])

The JNIDS model (Joint National Intelligence Development Staff) [5] is similar to the spiral model inthat it is also iterative and incremental. There are, however, six tasks in the JNIDS model: requirementsanalysis, team orchestration (i.e. the team-building stages, ``forming, storming, norming, andperforming"), design, coding, integration, and system implementation (delivery and maintenance). Themodel prescribes to iterate through all six tasks in every phase of software development. There are fivephases (requirements identification, prototype development, the breadth of system functionality, systemfunctionality refinement, and transition). They differ in the amount of time and effort they dedicate toeach specific task. The first phase focuses most on requirements analysis, the second one focuses most onteam orchestration, and so on. The last phase is concentrated most on integration and maintenance. Henceon the time axis the shift of the focus of attention in different phases generates a waterfall-like shape if thesix tasks are put on the ordinal axis. However, an important difference between the classical waterfall andJNIDS models is that in the JNIDS model developers conduct their activities through all tasks in eachphase.

The Unified Process for object-oriented software development [24], Figure 4, has recently becomevery popular. It is also iterative and incremental, just like the spiral and JNIDS models. All of itsiterations go through five core workflows (tasks) shown in Figure 4, and are grouped in four phases -inception (resulting in a global vision of the software product), elaboration (detailed analysis and designof the baseline architecture), construction (building the system's initial capability), and transition (productrelease). Just like in the JNIDS model, Figure 4 shows ``fuzzified" traces of the waterfall model in theUnified Process. The process is architecture-centric, meaning that its main deliverable is an executablearchitecture (the system), described by a set of models generated during the system development (use-case model, analysis model, design model, deployment model, implementation model, and test model).The models are represented using the standard UML diagrams . The Unified Process is also use-caseoriented, which means that generic scenarios of how the user or external applications use the system or itssubsystems bind all the workflows and drive the iterations.



Figure 4 - Core workflows, phases, and iterations in the Unified Process of object-orientedsoftware development

Being iterative, the Unified Process reduces additional development costs generated by unexpectedsituations (usually just a single iteration of work is lost). Iterating through all core workflows in everyiteration, the process is compliant with the reality of ever changing and incomplete user requirements.The Unified Process is also risk-driven - it enforces examining areas of highest risk in every phase andevery iteration, as well as doing the most critical tasks first. Hence it minimizes the risk of projectrunaways. Managers can easily adapt the Unified Process to different application types, project sizes,development teams, and levels of competence.

Because of the importance of the Unified Process for software project management today, commentson some other issues from the Unified Process perspective are included in the following chapters.

1.1.3 Software Project Management: Estimation:

Software Project Management• Software project management is especially difficult• Software project management : The Manager’s ViewProcess/Project/Product/PeoplePeopleProjectRFP Process ProductMethods ToolsMetrics• Numerical measures that quantify the degree to which software, a process or a project possesses a givenattribute

COREPHASES

WORKFLOWS

InceptionElaboration

Construction

Transition

Requirements

An iterationin the

Analysis

elaborationphase

Design

Implementation

Test



• Metrics help the followings– Determining software quality level– Estimating project schedules– Tracking schedule process– Determining software size and complexity– Determining project cost– Process improvement

Software Metrics• Without measure it is impossible to make a plan, detect problems, and improve a process and product• A software engineer collects measure and develops metrics so that indicators will be obtained• An indicator provides insight that enables the project manager or software engineers to adjust theprocess, the project, or the product to make things betterSoftware Metrics• The five essential, fundamental metrics:– Size (LOC, etc.)– Cost (in dollars)– Duration (in months)– Effort (in person‐month)– Quality (number of faults detected)Product Size Metrics• Conventional metrics– Size‐oriented metrics– Function‐oriented metrics– Empirical estimation models• Object‐Oriented metrics– Number of scenario scripts– Number of key classes– Number of support classes– Average number of support classes per key classes• User‐Case oriented metricsProduct Size Metrics (cont’d)• Web engineering product metrics– Number of static web pages– Number of dynamic web pages– Number of internal page links– Number of persistent page linksEstimate Uncertainty

1.1.4 Requirements Analysis Design

Size Estimation• The methods to achieve reliable size and costestimates:– LOC‐based estimation– FP‐based estimation– Empirical estimation models• COCOMOLOC‐based Estimation• The problems of lines of code (LOC)– Different languages lead to different lengths of code



– It is not clear how to count lines of code– A report, screen, or GUI generator can generate thousands of lines of code in minutes– Depending on the application, the complexity of code is different.

Function Point Analysis

The purpose of thisOne of the initial desiThe Five Components of Function Points

Data Functions

Internal Logical Files External Interface Files

Transactional Functions

External Inputs External Outputs External Inquiries

Internal Logical Files - The first data function allows users to utilize data they are responsible formaintaining. For example, a pilot may enter navigational data through a display in the cockpit prior todeparture. The data is stored in a file for use and can be modified during the mission. Therefore the pilotis responsible for maintaining the file that contains the navigational information. Logical groupings ofdata in a system, maintained by an end user, are referred to as Internal Logical Files (ILF).

External Interface Files - The second Data Function a system provides an end user is also related tological groupings of data. In this case the user is not responsible for maintaining the data. The dataresides in another system and is maintained by another user or system. The user of the system beingcounted requires this data for reference purposes only. For example, it may be necessary for a pilot toreference position data from a satellite or ground-based facility during flight. The pilot does not have theresponsibility for updating data at these sites but must reference it during the flight. Groupings of datafrom another system that are used only for reference purposes are defined as External Interface Files(EIF).

The remaining functions address the user's capability to access the data contained in ILFs and EIFs. Thiscapability includes maintaining, inquiring and outputting of data. These are referred to as TransactionalFunctions.

External Input - The first Transactional Function allows a user to maintain Internal Logical Files (ILFs)through the ability to add, change and delete the data. For example, a pilot can add, change and deletenavigational information prior to and during the mission. In this case the pilot is utilizing a transactionreferred to as an External Input (EI). An External Input gives the user the capability to maintain the datain ILF's through adding, changing and deleting its contents.

External Output - The next Transactional Function gives the user the ability to produce outputs. Forexample a pilot has the ability to separately display ground speed, true air speed and calibrated air speed.The results displayed are derived using data that is maintained and data that is referenced. In functionpoint terminology the resulting display is called an External Output (EO).



External Inquiries - The final capability provided to users through a computerized system addresses therequirement to select and display specific data from files. To accomplish this a user inputs selectioninformation that is used to retrieve data that meets the specific criteria. In this situation there is nomanipulation of the data. It is a direct retrieval of information contained on the files. For example if apilot displays terrain clearance data that was previously set, the resulting output is the direct retrieval ofstored information. These transactions are referred to as External Inquiries (EQ).

In addition to the five functional components described above there are two adjustment factors that needto be considered in Function Point Analysis.

Functional Complexity - The first adjustment factor considers the Functional Complexity for eachunique function. Functional Complexity is determined based on the combination of data groupings anddata elements of a particular function. The number of data elements and unique groupings are countedand compared to a complexity matrix that will rate the function as low, average or high complexity.Each of the five functional components (ILF, EIF, EI, EO and EQ) has its own unique complexitymatrix. The following is the complexity matrix for External Outputs.

1-5 DETs 6 - 19 DETs 20+ DETs

0 or 1 FTRs L L A

2 or 3 FTRs L A H

4+ FTRs A H H

Complexity UFP

L (Low) 4

A (Average) 5

H (High) 7

Using the examples given above and their appropriate complexity matrices, the function point count forthese functions would be:

FunctionName

FunctionType

RecordElementType

DataElementType

File TypesReferenced

UnadjustedFPs

Navigationaldata

ILF 3 36 n/a 10

Positionaldata

EIF 1 3 n/a 5

Navigationaldata - add

EI n/a 36 1 4

Navigationaldata - change

EI n/a 36 1 4

Navigationaldata - delete

EI n/a 3 1 3

Groundspeed

EO n/a 20 3 7



display

Air speeddisplay

EO n/a 20 3 7

Calibratedairspeed display

EO n/a 20 3 7

Terrainclearancedisplay

EQ n/a 1 1 3

Total unadjusted count 50 UFPs

All of the functional components are analyzed in this way and added together to derive an UnadjustedFunction Point count.

Value Adjustment Factor - The Unadjusted Function Point count is multiplied by the secondadjustment factor called the Value Adjustment Factor. This factor considers the system's technical andoperational characteristics and is calculated by answering 14 questions. The factors are:

1. Data CommunicationsThe data and control information used in the application are sent or received over communicationfacilities.

2. Distributed Data ProcessingDistributed data or processing functions are a characteristic of the application within the applicationboundary.

3. PerformanceApplication performance objectives, stated or approved by the user, in either response or throughput,influence (or will influence) the design, development, installation and support of the application.

4. Heavily Used ConfigurationA heavily used operational configuration, requiring special design considerations, is a characteristic ofthe application.

5. Transaction RateThe transaction rate is high and influences the design, development, installation and support.

6. On-line Data EntryOn-line data entry and control information functions are provided in the application.

7. End -User EfficiencyThe on-line functions provided emphasize a design for end-user efficiency.

8. On-line UpdateThe application provides on-line update for the internal logical files.

9. Complex ProcessingComplex processing is a characteristic of the application.

10. Reusability



The application and the code in the application have been specifically designed, developed andsupported to be usable in other applications.

11. Installation EaseConversion and installation ease are characteristics of the application. A conversion and installation planand/or conversion tools were provided and tested during the system test phase.

12. Operational EaseOperational ease is a characteristic of the application. Effective start-up, backup and recoveryprocedures were provided and tested during the system test phase.

13. Multiple SitesThe application has been specifically designed, developed and supported to be installed at multiple sitesfor multiple organizations.

14. Facilitate ChangeThe application has been specifically designed, developed and supported to facilitate change.

Each of these factors is scored based on their influence on the system being counted. The resulting scorewill increase or decrease the Unadjusted Function Point count by 35%. This calculation provides us withthe Adjusted Function Point count.

An Approach to Counting Function PointsThere are several approaches used to count function points. Q/P Management Group, Inc. has found thata structured workshop conducted with people who are knowledgeable of the functionality providedthrough the application is an efficient, accurate way of collecting the necessary data. The workshopapproach allows the counter to develop a representation of the application from a functional perspectiveand educate the participants about function points.

Function point counting can be accomplished with minimal documentation. However, the accuracy andefficiency of the counting improves with appropriate documentation. Examples of appropriatedocumentation are:

Design specifications Display designs Data requirements (Internal and External) Description of user interfaces

Function point counts are calculated during the workshop and documented with both a diagram thatdepicts the application and worksheets that contain the details of each function discussed.

Benefits of Function Point AnalysisOrganizations that adopt Function Point Analysis as a software metric realize many benefits including:improved project estimating; understanding project and maintenance productivity; managing changingproject requirements; and gathering user requirements. Each of these is discussed below.

Estimating software projects is as much an art as a science. While there are several environmentalfactors that need to be considered in estimating projects, two key data points are essential. The first isthe size of the deliverable. The second addresses how much of the deliverable can be produced within adefined period of time. Size can be derived from Function Points, as described above. The secondrequirement for estimating is determining how long it takes to produce a function point. This delivery



rate can be calculated based on past project performance or by using industry benchmarks. The deliveryrate is expressed in function points per hour (FP/Hr) and can be applied to similar proposed projects toestimate effort (i.e. Project Hours = estimated project function points FP/Hr).

Productivity measurement is a natural output of Function Points Analysis. Since function points aretechnology independent they can be used as a vehicle to compare productivity across dissimilar toolsand platforms. More importantly, they can be used to establish a productivity rate (i.e. FP/Hr) for aspecific tool set and platform. Once productivity rates are established they can be used for projectestimating as described above and tracked over time to determine the impact continuous processimprovement initiatives have on productivity.

In addition to delivery productivity, function points can be used to evaluate the support requirements formaintaining systems. In this analysis, productivity is determined by calculating the number of functionpoints one individual can support for a given system in a year (i.e. FP/FTE year). When compared withother systems, these rates help to identify which systems require the most support. The resulting analysishelps an organization develop a maintenance and replacement strategy for those systems that have highmaintenance requirements.

Managing Change of Scope for an in-process project is another key benefit of Function Point Analysis.Once a project has been approved and the function point count has been established, it becomes arelatively easy task to identify, track and communicate new and changing requirements. As requestscome in from users for new displays or capabilities, function point counts are developed and appliedagainst the rate. This result is then used to determine the impact on budget and effort. The user and theproject team can then determine the importance of the request against its impact on budget and schedule.At the conclusion of the project the final function point count can be evaluated against the initialestimate to determine the effectiveness of requirements gathering techniques. This analysis helps toidentify opportunities to improve the requirements definition process.

Communicating Functional Requirements was the original objective behind the development of functionpoints. Since it avoids technical terminology and focuses on user requirements it is an excellent vehicleto communicate with users. The techniques can be used to direct customer interviews and document theresults of Joint Application Design (JAD) sessions. The resulting documentation provides a frameworkthat describes user and technical requirements.

In conclusion, Function Point Analysis has proven to be an accurate technique for sizing, documentingand communicating a system's capabilities. It has been successfully used to evaluate the functionality ofreal-time and embedded code systems, such as robot based warehouses and avionics, as well astraditional data processing. As computing environments become increasingly complex, it is proving tobe a valuable tool that accurately reflects the systems we deliver and maintain.

COCOMO Model

The COCOMO cost estimation model is used by thousands of software project managers, and is basedon a study of hundreds of software projects. Unlike other cost estimation models, COCOMO is an openmodel, so all of the details are published, including:

The underlying cost estimation equations Every assumption made in the model (e.g. "the project will enjoy good management") Every definition (e.g. the precise definition of the Product Design phase of a project) The costs included in an estimate are explicitly stated (e.g. project managers are included,

secretaries aren't)



Because COCOMO is well defined, and because it doesn't rely upon proprietary estimation algorithms,Costar offers these advantages to its users:

COCOMO estimates are more objective and repeatable than estimates made by methods relyingon proprietary models

COCOMO can be calibrated to reflect your software development environment, and to producemore accurate estimates

Costar is a faithful implementation of the COCOMO model that is easy to use on small projects, and yetpowerful enough to plan and control large projects.

Typically, you'll start with only a rough description of the software system that you'll be developing, andyou'll use Costar to give you early estimates about the proper schedule and staffing levels. As you refineyour knowledge of the problem, and as you design more of the system, you can use Costar to producemore and more refined estimates.

Costar allows you to define a software structure to meet your needs. Your initial estimate might be madeon the basis of a system containing 3,000 lines of code. Your second estimate might be more refined sothat you now understand that your system will consist of two subsystems (and you'll have a moreaccurate idea about how many lines of code will be in each of the subsystems). Your next estimate willcontinue the process -- you can use Costar to define the components of each subsystem. Costar permitsyou to continue this process until you arrive at the level of detail that suits your needs.

One word of warning: It is so easy to use Costar to make software cost estimates, that it's possible tomisuse it -- every Costar user should spend the time to learn the underlying COCOMO assumptions anddefinitions from Software Engineering Economics and Software Cost Estimation with COCOMO II.

The most fundamental calculation in the COCOMO model is the use of the Effort Equation to estimatethe number of Person-Months required to develop a project. Most of the other COCOMO results,including the estimates for Requirements and Maintenance, are derived from this quantity.

Source Lines of Code

The COCOMO calculations are based on your estimates of a project's size in Source Lines of Code(SLOC). SLOC is defined such that:

Only Source lines that are DELIVERED as part of the product are included -- test drivers andother support software is excluded

SOURCE lines are created by the project staff -- code created by applications generators isexcluded

One SLOC is one logical line of code Declarations are counted as SLOC Comments are not counted as SLOC

The original COCOMO 81 model was defined in terms of Delivered Source Instructions, which are verysimilar to SLOC. The major difference between DSI and SLOC is that a single Source Line of Code maybe several physical lines. For example, an "if-then-else" statement would be counted as one SLOC, butmight be counted as several DSI.

The Scale Drivers



In the COCOMO II model, some of the most important factors contributing to a project's duration andcost are the Scale Drivers. You set each Scale Driver to describe your project; these Scale Driversdetermine the exponent used in the Effort Equation.

The 5 Scale Drivers are:

Precedentedness Development Flexibility Architecture / Risk Resolution Team Cohesion Process Maturity

Note that the Scale Drivers have replaced the Development Mode of COCOMO 81. The first two ScaleDrivers, Precedentedness and Development Flexibility actually describe much the same influences thatthe original Development Mode did.

Cost Drivers

COCOMO II has 17 cost drivers ï¿½ you assess your project, development environment, and team to seteach cost driver. The cost drivers are multiplicative factors that determine the effort required to completeyour software project. For example, if your project will develop software that controls an airplane'sflight, you would set the Required Software Reliability (RELY) cost driver to Very High. That ratingcorresponds to an effort multiplier of 1.26, meaning that your project will require 26% more effort than atypical software project.

.COCOMO II defines each of the cost drivers, and the Effort Multiplier associated with each rating.Check the Costar help for details about the definitions and how to set the cost drivers.

COCOMO II Effort Equation

The COCOMO II model makes its estimates of required effort (measured in Person-Months ï¿½ PM)based primarily on your estimate of the software project's size (as measured in thousands of SLOC,KSLOC)):

Effort = 2.94 * EAF * (KSLOC)E

WhereEAF Is the Effort Adjustment Factor derived from the Cost DriversE Is an exponent derived from the five Scale Drivers

As an example, a project with all Nominal Cost Drivers and Scale Drivers would have an EAF of 1.00and exponent, E, of 1.0997. Assuming that the project is projected to consist of 8,000 source lines ofcode, COCOMO II estimates that 28.9 Person-Months of effort is required to complete it:

Effort = 2.94 * (1.0) * (8)1.0997 = 28.9 Person-Months

Effort Adjustment Factor

The Effort Adjustment Factor in the effort equation is simply the product of the effort multiplierscorresponding to each of the cost drivers for your project.



For example, if your project is rated Very High for Complexity (effort multiplier of 1.34), and Low forLanguage & Tools Experience (effort multiplier of 1.09), and all of the other cost drivers are rated to beNominal (effort multiplier of 1.00), the EAF is the product of 1.34 and 1.09.

Effort Adjustment Factor = EAF = 1.34 * 1.09 = 1.46


COCOMO II Schedule Equation

The COCOMO II schedule equation predicts the number of months required to complete your softwareproject. The duration of a project is based on the effort predicted by the effort equation:

Duration = 3.67 * (Effort)SE

WhereEffort Is the effort from the COCOMO II effort equationSE Is the schedule equation exponent derived from the five Scale Drivers

Continuing the example, and substituting the exponent of 0.3179 that is calculated from the scaledrivers, yields an estimate of just over a year, and an average staffing of between 3 and 4 people:

Duration = 3.67 * (42.3)0.3179 = 12.1 months

Average staffing = (42.3 Person-Months) / (12.1 Months) = 3.5 people

The SCED Cost Driver

The COCOMO cost driver for Required Development Schedule (SCED) is unique, and requires aspecial explanation.

The SCED cost driver is used to account for the observation that a project developed on an acceleratedschedule will require more effort than a project developed on its optimum schedule. A SCED rating ofVery Low corresponds to an Effort Multiplier of 1.43 (in the COCOMO II.2000 model) and means thatyou intend to finish your project in 75% of the optimum schedule (as determined by a previousCOCOMO estimate). Continuing the example used earlier, but assuming that SCED has a rating of VeryLow, COCOMO produces these estimates:

Duration = 75% * 12.1 Months = 9.1 Months

Effort Adjustment Factor = EAF = 1.34 * 1.09 * 1.43 = 2.09


Average staffing = (60.4 Person-Months) / (9.1 Months) = 6.7 people

Notice that the calculation of duration isn't based directly on the effort (number of Person-Months) ï¿½instead it's based on the schedule that would have been required for the project assuming it had beendeveloped on the nominal schedule. Remember that the SCED cost driver means "accelerated from thenominal schedule".



The Costar command Constraints | Constrain Project displays a dialog box that lets you trade offduration vs. effort (SCED is set for you automatically). You can use the dialog box to constrain yourproject to have a fixed duration, or a fixed cost.

1.1.5 Project Scheduling – Scheduling, Earned Value Analysis:

Software development is an extremely dynamic and fluid business, and it is difficult to planeverything at the beginning of a project. Therefore, efficient management of software projects must bebased on some explicit, strategic goals and organization's interests. There are a number of useful lines tofollow in that sense. Some of them are.

• balancing the need for structure and process control in software development with the need forflexibility, informality, and more effective communication processes;

• establishing software measurement programs and and enfocing accountability for completion ofsoftware development milestones;

• making management objectives and product vision clear to the development team members (this is veryimportnt in practice, because far too often developers are in total ignorance of the broader strategy of acompany, and the tactical decisions made by management to advance this strategy seem to themarbitrary and even hostile);

• identifying the most critical issues of the project and stressing the need to allocate most developmentresources, time, and efforts to such issues;

• organizing more visible and formal management processes for reviewing and approving potentialproduct enhancements;

• emphasizing management approaches that facilitate flexibility and creativity within clearly definedboundaries.

• keeping-up with technological developments by enforcing life-long learning, training, courses, andseminars;

• developing more globally focused, culturally sensitive management capabilities;• involving end-users in the development process in order to constantly provide advice on using the

product in the real world, thus eliminating the customer-developer gap;• promoting orientation towards strategic business partnerships.

There is also a large number of managerial techniques that help monitor software productdevelopment on the day -to-day basis and make tactical decisions relevant to the development process.

• maintaining progress charts that show the percentage of completion for each module, at any givenmoment of product development;

• keeping track of all relevant facts about the product (e.g., previous versions, delivery dates, currentversion), the development process (the problems encountered, resulting delays, and the reasons why theyhave occurred), and discarded design alternatives in the external group memory (it is usually a special-purpose project-management software, or a site on the organization's server or Intranet, and sometimeseven a site on the Internet); the external group memory can also serve as a board for discussion on all therelevant ideas that arise in the course of the project;

• estimating time and effort needed for each designer to complete a short-term task, e.g. an iteration in aniterative development process; for that purpose, each designer may be required to initially fill-up andconstantly update a planning sheet that contains both the designer's original estimates and actualmeasures (in days) of how long does it take to complete each activity for the task (activities may includeanalysis, design, coding, testing, and so on);

• emphasizing progress review mechanisms across the development effort;• applying mechanisms of recognizing, rewarding, and leveraging extraordinary efforts and/or

hyperproductivity, as an avenue to promote and retain key technological leaders;• adapting the software development process to the characteristics of the product being developed;• increasing parallelism in product development by reducing linear, sequential activities, encouraging

relevant communication and social interactions among the team members, and changing the work modes



when necessary;• insisting on creating multiple design views, such as structural, functional, object-oriented, event-based,

and data-flow; although sometimes redundant, multiple design views help cover design from multipleperspectives and make it more complete and more efficient; enforcing the feedback mechanism in thedevelopment process, in order to detect inconsistencies in design as early as possible and reduce thecosts of fixing them.

Risk Assessment

In order to prevent project runaways, meet deadlines, stay within the project's budget, andsimultaneously maintain the product's high quality standards, it is essential to timely identify andperiodically evaluate certain critical factors. Such factors include

• estimating the project's size in the early phases - the project's size affects how the deadlines will be setup, and is positively correlated with monetary expense and risk;

• setting up the deadlines realistically - as a result, the necessary time to establish the rhythm of theproject, prevent delays, and enter a steady state in which the effort is equally distributed from thebeginning of the project, without putting an extra workload to the team members at the end of the projectphases;

• collecting and studying reports on other similar projects - this provides the possibility of learning fromthe other projects' and other teams' experiences; in that sense, a process data base is essential for anorganization that wants to go higher than Level 2 on the CMM level ladder; engineering managementdepends on measurements, and their proper use, and this data base is to be regarded as an organizationalasset, and it is to be properly managed;

• top management commitment - if top management does not play a strong, active role in the project frominitiation through implementation, then all other risks and issues may be impossible to address in atimely manner;

• failure to gain user commitment - when the users are actively involved in the requirements determinationprocess, it creates a sense of ownership, thereby minimizing the risk that the end-user expectations willnot be met and that the system will be rejected;

• timeliness of additional user requirements - it is essential to have the users involved in the developmentprocess from the beginning to the end; however, it is highly preferable to have the requirements frozenat a certain point in development;

• familiarity with technology - the higher the organization’s experience with application languages,technology databases, hardware, and operating systems, the lower the risk in the project;

• insufficient/inappropriate staffing - the risk of failing to provide adequate staffing throughout the projectcan be mitigated by using disciplined development processes and methodologies to break the projectdown into manageable chunks, and developing contingency plans; the degree of structure in theproject's outputs - it is negatively correlated with the risk in the project;

In the context of the Unified Process of software development, it is adoptedthat one can never fully eliminate risks; at best, one can manage them. For that reason, the UnifiedProcess stresses the need to drive software development as an architecture-centric activity. Architecture-centric approach forces the risk factors to emerge early in the development process and make the processsimultaneously risk-driven - when the risk factors are identified early, managers can take steps tomitigate them. Experienced software project managers recommend to maintain a running list of project'stop ten risk factors and use that list to drive each release.

UNIT II REQUIREMENTS ANALYSIS AND SPECIFICATION 9Software Requirements: Functional and Non-Functional, User requirements, System requirements,Software Requirements Document – Requirement Engineering Process: Feasibility Studies,Requirements elicitation and analysis, requirements validation, requirements management-Classicalanalysis: Structured system Analysis, Petri Nets-Data Dictionary.

2.1.1 Software Requirements: Functional and Non-Functional, User requirements, System



requirements, Software Requirements Document

Requirements analysis in systems engineering and software engineering, encompasses those tasks thatgo into determining the needs or conditions to meet for a new or altered product, taking account of thepossibly conflicting requirements of the various stakeholders, such as beneficiaries or users.

Requirements analysis is critical to the success of a development project. Requirements must beactionable, measurable, testable, related to identified business needs or opportunities, and defined to alevel of detail sufficient for system design. Requirements can be functional and non-functional.

Requirements engineering

Systematic requirements analysis is also known as requirements engineering. It is sometimes referred toloosely by names such as requirements gathering, requirements capture, or requirements specification.The term requirements analysis can also be applied specifically to the analysis proper, as opposed toelicitation or documentation of the requirements, for instance.

Requirement engineering according to Laplante (2007) is "a subdiscipline of systems engineering andsoftware engineering that is concerned with determining the goals, functions, and constraints ofhardware and software systems." In some life cycle models, the requirement engineering processbegins with a feasibility study activity, which leads to a feasibility report. If the feasibility studysuggest that the product should be developed, then requirement analysis can begin. If requirementanalysis precedes feasibility studies, which may foster outside the box thinking, then feasibility shouldbe determined before requirements are finalized.

Requirements analysis topics

Stakeholder identification

See Stakeholder analysis for a discussion of business uses. Stakeholders (SH) are persons ororganizations (legal entities such as companies, standards bodies) which have a valid interest in thesystem. They may be affected by it either directly or indirectly. A major new emphasis in the 1990s wasa focus on the identification of stakeholders. It is increasingly recognized that stakeholders are notlimited to the organization employing the analyst. Other stakeholders will include:

• anyone who operates the system (normal and maintenance operators)

• anyone who benefits from the system (functional, political, financial and socialbeneficiaries)

• anyone involved in purchasing or procuring the system. In a mass-market productorganization, product management, marketing and sometimes sales act as surrogateconsumers (mass-market customers) to guide development of the product

• organizations which regulate aspects of the system (financial, safety, and otherregulators)

• people or organizations opposed to the system (negative stakeholders; see also Misuse case)

• organizations responsible for systems which interface with the system under design



• those organizations who integrate horizontally with the organization for whom the analystis designing the system

Types of Requirements

Requirements are categorized in several ways. The following are common categorizations ofrequirements that relate to technical management:

Customer Requirements

Statements of fact and assumptions that define the expectations of the system in terms ofmission objectives, environment, constraints, and measures of effectiveness and suitability(MOE/MOS). The customers are those that perform the eight primary functions of systemsengineering, with special emphasis on the operator as the key customer. Operationalrequirements will define the basic need and, at a minimum, answer the questions posed in thefollowing listing:

• Operational distribution or deployment: Where will the system be used?

• Mission profile or scenario: How will the system accomplish its missionobjective?

• Performance and related parameters: What are the critical system parameters toaccomplish the mission?

• Utilization environments: How are the various system components to be used?

• Effectiveness requirements: How effective or efficient must the system be inperforming its mission?

• Operational life cycle: How long will the system be in use by the user?

• Environment: What environments will the system be expected to operate in aneffective manner?

Functional Requirements

Functional requirements explain what has to be done by identifying the necessary task, action oractivity that must be accomplished. Functional requirements analysis will be used as the toplevelfunctions for functional analysis.

Non-functional Requirements

Non-functional requirements are requirements that specify criteria that can be used to judge theoperation of a system, rather than specific behaviors.

Performance Requirements

The extent to which a mission or function must be executed; generally measured in terms ofquantity, quality, coverage, timeliness or readiness. During requirements analysis,performance (how well does it have to be done) requirements will be interactively developedacross all identified functions based on system life cycle factors; and characterized in termsof the degree of certainty in their estimate, the degree of criticality to system success, andtheir relationship to other requirements.

Design Requirements



The ―build to,‖ ―code to,‖ and ―buy to‖ requirements for products and ―how toexecute‖ requirements for processes expressed in technical data packages andtechnical manuals.

Derived Requirements

Requirements that are implied or transformed from higher-level requirement. Forexample, a requirement for long range or high speed may result in a design requirementfor low weight.

Allocated Requirements

A requirement that is established by dividing or otherwise allocating a high-level requirementinto multiple lower-level requirements. Example: A 100-pound item that consists of twosubsystems might result in weight requirements of 70 pounds and 30 pounds for the twolower-level items.

Well-known requirements categorization models include FURPS and FURPS+, developed atHewlett-Packard.

Requirements analysis issues

Stakeholder issues

Steve McConnell, in his book Rapid Development, details a number of ways users can inhibitrequirements gathering:

• Users do not understand what they want or users don't have a clear idea of theirrequirements

• Users will not commit to a set of written requirements

• Users insist on new requirements after the cost and schedule have been fixed

• Communication with users is slow

• Users often do not participate in reviews or are incapable of doing so

• Users are technically unsophisticated

• Users do not understand the development process

• Users do not know about present technology

This may lead to the situation where user requirements keep changing even when system or productdevelopment has been started.

2.1.2 Requirement Engineering Process: Feasibility Studies, Requirements elicitation and analysis

The Systems Development Life Cycle (SDLC), or Software Development Life Cycle in systemsengineering, information systems and software engineering, is the process of creating or alteringsystems, and the models and methodologies that people use to develop these systems. The conceptgenerally refers to computer or information systems.

In software engineering the SDLC concept underpins many kinds of software development



methodologies. These methodologies form the framework for planning and controlling the creation of aninformation system[1]: the software development process.

The Systems Development Life Cycle (SDLC), or Software Development Life Cycle in systemsengineering, information systems and software engineering, is the process of creating or alteringsystems, and the models and methodologies that people use to develop these systems. The conceptgenerally refers to computer or information systems.

In software engineering the SDLC concept underpins many kinds of software developmentmethodologies. These methodologies form the framework for planning and controlling the creation of aninformation system: the software development process.

SYSTEMS DEVELOPMENT PHASES

The System Development Life Cycle framework provides a sequence of activities for system designersand developers to follow. It consists of a set of steps or phases in which each phase of the SDLC usesthe results of the previous one.

A Systems Development Life Cycle (SDLC) adheres to important phases that are essential fordevelopers, such as planning, analysis, design, and implementation, and are explained in the sectionbelow. A number of system development life cycle (SDLC) models have been created: waterfall,fountain, spiral, build and fix, rapid prototyping, incremental, and synchronize and stabilize. The oldestof these, and the best known, is the waterfall model: a sequence of stages in which the output of eachstage becomes the input for the next. These stages can be characterized and divided up in different ways,including the following

Project planning, feasibility study: Establishes a high-level view of the intended project anddetermines its goals.

Systems analysis, requirements definition: Refines project goals into defined functions andoperation of the intended application. Analyzes end-user information needs.

Systems design: Describes desired features and operations in detail, including screen layouts,business rules, process diagrams, pseudocode and other documentation.

Implementation: The real code is written here. Integration and testing: Brings all the pieces together into a special testing environment, then

checks for errors, bugs and interoperability. Acceptance, installation, deployment: The final stage of initial development, where the

software is put into production and runs actual business. Maintenance: What happens during the rest of the software's life: changes, correction,

additions, moves to a different computing platform and more. This, the least glamorous andperhaps most important step of all, goes on seemingly forever.

System analysis

The goal of system analysis is to determine where the problem is in an attempt to fix the system. Thisstep involves breaking down the system in different pieces to analyze the situation, analyzing projectgoals, breaking down what needs to be created and attempting to engage users so that definiterequirements can be defined.

Requirements analysis sometimes requires individuals/teams from client as well as service provider



sides to get detailed and accurate requirements; often there has to be a lot of communication to and fromto understand these requirements. Requirement gathering is the most crucial aspect as many timescommunication gaps arise in this phase and this leads to validation errors and bugs in the softwareprogram.

Design

In systems design the design functions and operations are described in detail, including screen layouts,business rules, process diagrams and other documentation. The output of this stage will describe the newsystem as a collection of modules or subsystems.

The design stage takes as its initial input the requirements identified in the approved requirementsdocument. For each requirement, a set of one or more design elements will be produced as a result ofinterviews, workshops, and/or prototype efforts.

Design elements describe the desired software features in detail, and generally include functionalhierarchy diagrams, screen layout diagrams, tables of business rules, business process diagrams,pseudocode, and a complete entity-relationship diagram with a full data dictionary. These designelements are intended to describe the software in sufficient detail that skilled programmers may developthe software with minimal additional input design.

Implementation

Modular and subsystem programming code will be accomplished during this stage. Unit testing andmodule testing are done in this stage by the developers. This stage is intermingled with the next in thatindividual modules will need testing before integration to the main project.

Testing

The code is tested at various levels in software testing. Unit, system and user acceptance testings areoften performed. This is a grey area as many different opinions exist as to what the stages of testing areand how much if any iteration occurs. Iteration is not generally part of the waterfall model, but usuallysome occur at this stage. In the testing the whole system is test one by one

Following are the types of testing:

Defect testing Path testing Data set testing Unit testing System testing Integration testing Black box testing White box testing Regression testing Automation testing User acceptance testing Performance testing



Operations and maintenance

The deployment of the system includes changes and enhancements before the decommissioning orsunset of the system. Maintaining the system is an important aspect of SDLC. As key personnel changepositions in the organization, new changes will be implemented, which will require system updates.

SYSTEMS ANALYSIS AND DESIGN

The Systems Analysis and Design (SAD) is the process of developing Information Systems (IS) thateffectively use of hardware, software, data, process, and people to support the company’s businessobjectives.

SYSTEMS DEVELOPMENT LIFE CYCLE TOPICS

Management and control

SDLC Phases Related to Management Controls.

The Systems Development Life Cycle (SDLC) phases serve as a programmatic guide to project activityand provide a flexible but consistent way to conduct projects to a depth matching the scope of theproject. Each of the SDLC phase objectives are described in this section with key deliverables, adescription of recommended tasks, and a summary of related control objectives for effectivemanagement. It is critical for the project manager to establish and monitor control objectives during eachSDLC phase while executing projects. Control objectives help to provide a clear statement of the desiredresult or purpose and should be used throughout the entire SDLC process. Control objectives can begrouped into major categories (Domains), and relate to the SDLC phases as shown in the figure.

To manage and control any SDLC initiative, each project will be required to establish some degree of aWork Breakdown Structure (WBS) to capture and schedule the work necessary to complete the project.The WBS and all programmatic material should be kept in the “Project Description” section of theproject notebook. The WBS format is mostly left to the project manager to establish in a way that bestdescribes the project work. There are some key areas that must be defined in the WBS as part of the



SDLC policy. The following diagram describes three key areas that will be addressed in the WBS in amanner established by the project manager.

Work breakdown structured organization

Work Breakdown Structure.

The upper section of the Work Breakdown Structure (WBS) should identify the major phases andmilestones of the project in a summary fashion. In addition, the upper section should provide anoverview of the full scope and timeline of the project and will be part of the initial project descriptioneffort leading to project approval. The middle section of the WBS is based on the seven SystemsDevelopment Life Cycle (SDLC) phases as a guide for WBS task development. The WBS elementsshould consist of milestones and “tasks” as opposed to “activities” and have a definitive period (usuallytwo weeks or more). Each task must have a measurable output (e.x. document, decision, or analysis). AWBS task may rely on one or more activities (e.g. software engineering, systems engineering) and mayrequire close coordination with other tasks, either internal or external to the project. Any part of theproject needing support from contractors should have a Statement of work (SOW) written to include theappropriate tasks from the SDLC phases. The development of a SOW does not occur during a specificphase of SDLC but is developed to include the work from the SDLC process that may be conducted byexternal resources such as contractors and struct.

Baselines in the SDLC

Baselines are an important part of the Systems Development Life Cycle (SDLC). These baselines areestablished after four of the five phases of the SDLC and are critical to the iterative nature of the model.Each baseline is considered as a milestone in the SDLC.

Functional Baseline: established after the conceptual design phase. Allocated Baseline: established after the preliminary design phase. Product Baseline: established after the detail design and development phase. Updated Product Baseline: established after the production construction phase.

Complementary to SDLC

Complementary Software development methods to Systems Development Life Cycle (SDLC) are:

Software Prototyping Joint Applications Design (JAD)



Rapid Application Development (RAD) Extreme Programming (XP); extension of earlier work in Prototyping and RAD. Open Source Development End-user development Object Oriented Programming

2.1.3 requirements validation, requirements management

The goal of this effort is to define a common set of resources, formats and RESTful services for the usein Requirements Definition and Management tools and use by (for example) systems engineering orALM tools that will enable the effective use of requirements across a development life-cycle.

Requirements Management (RM) resources define the requirements or capabilities of a system or theoutcome of some programme of work. We use the term system entirely generally and without prejudiceto software, hardware, IT, regulatory, business etc.

Requirements are the basis for defining what the system stakeholders (users, customers, suppliers and soon) need from a system and also what the system must do in order to meet those needs, and how thesurrounding processes must be orchestrated so that quality, scope and timescale objectives are satisfied.The discipline of requirements management involves many activities including elicitation, definition,documentation, analysis, decomposition, validation and justification; it involves managing changes torequirements and establishing and reasoning about their interrelationships. In involves the creation ofassets which are invariably related to other systems and processes. RM is inherently multi-disciplinaryand across the life-cycle; it brings together all assets across the life-cycle, ascribing them meaning,captures their dependencies and interrelationships and ultimately, captures the way in which theytogether produce the desired system.

Requirements management activities

Elicitation, definition and communication introduce requirements in such a way that relevantstakeholders can understand and agree that the system will meet their needs.

Gathering requirements and related assets into a coherent set, for example as a set ofrequirements documents, as part of forming a precise overarching specification of the system.Such a set of requirements is often part of a contractual agreement between parties, for example.

Analysis aids the understanding of requirements and enables the expression of refactored,decomposed, refined, elaborated, or clarified requirements. Assets such as system models maybe created during such analysis.

The need to validate the system induces the need to create test requirements that demonstratethat all requirements have been met, and thus, for example, that contractual obligations havebeen discharged.

The need to deal with ambiguity, complexity or testability of a requirement leads to lower-level,related derived artefacts. These derived artefacts may be requirements, or they could be fromsome other system, such as change requests, diagrams stored in a PLE system and so on.

The recording and management of the links created as part of each of these processes is centralto understanding the meaning of requirements, assessing the impact of proposed or actualchange and, through the recording of rationale information, validation that lower-levelrequirements are correctly derived from higher-level requirements.

The need to plan the scope of a release or milestone in order that the requirements that are to bemet are known and meaningful and will meet the stakeholders’ needs.



Traceability analysis

Impact analysis exploits the links created during such derivation and analysis in order to understand theramifications of actual or proposed changes to higher-level requirements. In this way the impact to thesystem, or aspects of its delivery can be assessed and acted upon.

Derivation analysis exploits links in order to inform cost/benefit analysis processes, or to understand therationale for some parts of the system, and the ramifications of actual or proposed change to those parts.

Coverage analysis informs planning and progress processes and it also provides verification informationon the satisfaction of a requirement by other assets, and contributes validation information to the qualityprocesses that are responsible for the creation and management of test requirements and other test-related assets.

In each of these kinds of trace analysis, the type of links being analyzed is significant, as is thejustification argument which describes why that link is present.

Management of change and auditing

Changes to requirements reflect changing needs or system behaviours. Trace analysis informs changeprocesses, as do other life-cycle characteristics, such as stability of the requirement. Auditing processesmay be used to support accountability for historical changes.

Requirements across the life-cycle

Requirements are the engineering language used to define not only the needs of the system stakeholdersbut also the performance and constraints of the system itself. As such, most other lifecycle activities areeither based on requirement data or heavily influence the requirement baseline of a development project.Once you have established processes for requirements management, change management, quality, andmodel-driven development, the next logical step is to integrate them in a collaborative ALMenvironment. This helps organisations not only break down silos, but can also accelerate processmaturity. For example, this approach can make it easier to demonstrate overall solution compliance andproduce cross discipline metrics that support more informed decision making.

Requirements Driven Development

When development activities are enabled using integrated requirements data, they provide focus,traceability and impact analysis. Developers can address issues and priorities without the need to accessmultiple repositories for information. Achieving process maturity in ALM depends on having a reliable,on-demand view of progress across the entire project in both agile development initiatives andtraditional waterfall approaches. Round-trip traceability enables analysis of the contents of each build,baseline, and release. Teams can see exactly which requirements, change requests, and developmenttasks have been implemented and which have not. In addition, the ALM platform displays thedifferences between different baselines. As such, teams can see what has changed. This approach makesit easier to demonstrate accountability, ensure security, and complete audits.

Requirements Driven Testing

One of the biggest challenges to testing maturity is to confine testing at the end of development whenbugs are most costly to fix, resources are low, and time is short. With the ability to map requirements



directly to test cases, test engineers can see exactly what requirements and features they should betesting, as well as who made changes and when. Teams can check to see that requirements matchspecifications, customer requests, regulations, and standards early in development. Testers can alsodescribe the tests associated with each requirement as soon as these are defined to ensure that testabilityconsidered when writing requirements.

Model Driven Development (MDD)Integrated MDD helps development teams better manage system complexity by focusing on high-leveldesign and development of application architecture and software using a graphical language. Thisenables team to translate requirements to a system model depicting functionality and to validate itsbehaviour through simulation. Often analysis of the results yields a route for further development andtest. Incorporating MDD into the ALM environment reduces the gap between the project requirementsand the final implementation. The ability to visualize requirements and trace them throughout thelifecycle improves understanding and project-wide impact analysis.

2.1.4 classical analysis

Introduction The Specification Document Informal Specifications Structured Systems Analysis Structured Systems Analysis: The Art Dealer Other Semiformal Techniques Entity-Relationship Modeling Finite State Machines Petri Nets Z Other Formal Techniques

Specification document — Contract between client and developer�Specifying what product must do and

Constraints on productAlmost always has a specified deadline for delivering product Incorporates constraints that product has tosatisfy

Portability (e.g., hardware or operating system)Reliability (e.g., needed to be operational 24 hours a day)

A set of acceptance criteriaA series of tests

To prove product satisfies its specifications

The Specification DocumentSolution strategies — General approach to building theproduct

Once development team fully understands the problemDevelopment team suggests solution strategiesDetermined if a solution satisfies client’s constraintsRecord keeping of discarded solution for future justificationsOne or more possible solution strategies are determined Client has to make a two-stage decision

(1) Whether client should computerize: Cost-benefit analysis(2) If so, which of viable solution strategies to adopt: Client’s optimization criterionE.g., minimizing total cost to client



E.g., maximizing return on investmentDevelopers advise client as to which of the viable solution strategies best satisfies the optimization

Informal SpecificationsSpecification document could consist of many pages of textEnglish or other natural languageClient’s wishes may be ignoredThere can be ambiguityStyle may not be good

2.1.5 Structured Systems Analysis

Use of graphics to specify softwareImportant technique of the 1970sA few popular techniques

Structures system analysis — A nine-step technique to analyze client’s needsStep-wise refinement is used in many of stepsStep 1: Draw the Data Flow Diagram (DFD)

A pictorial representation of all aspects of the logical data flowLogical data flow — What happensPhysical data flow — How it happens

Any non-trivial product contains many elementsDFD is developed by stepwise refinementFor large products a hierarchy of DFDs instead of one DFDConstructed by identifying data flows: Within requirements



Petri nets — Formal technique for describing concurrentinterrelated activitiesInvented by Carl Adam Petri, 1962Consists of four parts(1) A set of places(2) A set of transitions(3) An input function(4) An output functionOriginally of interest to automata theoristsFound wide applicability in computer science

Performance evaluationOperating systemsSoftware engineering

2.1.6 Petri Nets-Data Dictionary

Petri nets — Formal technique for describing concurrentinterrelated activitiesConsists of four parts(1) A set of places(2) A set of transitions(3) An input function(4) An output functionOriginally of interest to automata theoristsFound wide applicability in computer science

Performance evaluationOperating systems

Marking of a Petri netAssignment of tokensTokens enable transitions

Petri nets are non-deterministicIf more than one transition is able to fire, then any one canbe firedUse of inhibitor arcs an important extension: Small circleinstead of arrowA transition is enabled if

At least one token is in each of its (normal) input arcs andNo tokens on any of its inhibitor input arcs



UNIT III SOFTWARE DESIGN 9Design process – Design Concepts-Design Model– Design Heuristic – Architectural Design –Architectural styles, Architectural Design, Architectural Mapping using Data Flow- User InterfaceDesign: Interface analysis, Interface Design –Component level Design: Designing Class basedcomponents, traditional Components.

3.1.1 Design process

Software design is the process by which an agent creates a specification of a software artifact, intendedto accomplish goals, using a set of primitive components and subject to constraints.[1] Software designmay refer to either "all the activities involved in conceptualizing, framing, implementing, commissioning,and ultimately modifying complex systems" or "the activity following requirements specification andbefore programming, as ... [in] a stylized software engineering process.

Software design usually involves problem solving and planning a software solution. This includes bothlow-level component and algorithm design and high-level, architecture design.

Software design is both a process and a model. The design process is a sequence of steps that enable thedesigner to describe all aspects of the software to be built. It is important to note, however, that the designprocess is not simply a cookbook. Creative skill, past experience, a sense of what makes “good” software,and an overall commitment to quality are critical success factors for a competent design. The designmodel is the equivalent of an architect’s plans for a house. It begins by representing the totality of thething to be built (e.g., a three-dimensional rendering of the house) and slowly refines the thing to provideguidance for constructing each detail (e.g., the plumbing layout). Similarly, the design model that iscreated for software provides a variety of different views of the computer software. Basic designprinciples enable the software engineer to navigate the design process. Davis [DAV95] suggests a set ofprinciples for software design, which have been adapted and extended in the following list:



The design process should not suffer from “tunnel vision.” A good designer should consideralternative approaches, judging each based on the requirements of the problem, the resourcesavailable to do the job.

The design should be traceable to the analysis model. Because a single element of the designmodel often traces to multiple requirements, it is necessary to have a means for tracking howrequirements have been satisfied by the design model.

The design should not reinvent the wheel. Systems are constructed using a set of designpatterns, many of which have likely been encountered before. These patterns should always bechosen as an alternative to reinvention. Time is short and resources are limited! Design timeshould be invested in representing truly new ideas and integrating those patterns that alreadyexist.

The design should “minimize the intellectual distance” between the software and theproblem as it exists in the real world. That is, the structure of the software design should(whenever possible) mimic the structure of the problem domain.

The design should exhibit uniformity and integration. A design is uniform if it appears thatone person developed the entire thing. Rules of style and format should be defined for a designteam before design work begins. A design is integrated if care is taken in defining interfacesbetween design components.

The design should be structured to accommodate change. The design concepts discussed inthe next section enable a design to achieve this principle.

The design should be structured to degrade gently, even when aberrant data, events, oroperating conditions are encountered. Well- designed software should never “bomb.” It shouldbe designed to accommodate unusual circumstances, and if it must terminate processing, do so ina graceful manner.

Design is not coding, coding is not design. Even when detailed procedural designs are createdfor program components, the level of abstraction of the design model is higher than source code.The only design decisions made at the coding level address the small implementation details thatenable the procedural design to be coded.

The design should be assessed for quality as it is being created, not after the fact. A varietyof design concepts and design measures are available to assist the designer in assessing quality.

The design should be reviewed to minimize conceptual (semantic) errors. There is sometimesa tendency to focus on minutiae when the design is reviewed, missing the forest for the trees. Adesign team should ensure that major conceptual elements of the design (omissions, ambiguity,inconsistency) have been addressed before worrying about the syntax of the design model.

3.1.2 Design Concepts-Design Model

The design concepts provide the software designer with a foundation from which more sophisticatedmethods can be applied. A set of fundamental design concepts has evolved. They are:

1. Abstraction - Abstraction is the process or result of generalization by reducing the informationcontent of a concept or an observable phenomenon, typically in order to retain only informationwhich is relevant for a particular purpose.

2. Refinement - It is the process of elaboration. A hierarchy is developed by decomposing amacroscopic statement of function in a step-wise fashion until programming language statementsare reached. In each step, one or several instructions of a given program are decomposed intomore detailed instructions. Abstraction and Refinement are complementary concepts.

3. Modularity - Software architecture is divided into components called modules.4. Software Architecture - It refers to the overall structure of the software and the ways in which

that structure provides conceptual integrity for a system. A good software architecture will yield a



good return on investment with respect to the desired outcome of the project, e.g. in terms ofperformance, quality, schedule and cost.

5. Control Hierarchy - A program structure that represents the organization of a program componentand implies a hierarchy of control.

6. Structural Partitioning - The program structure can be divided both horizontally and vertically.Horizontal partitions define separate branches of modular hierarchy for each major programfunction. Vertical partitioning suggests that control and work should be distributed top down inthe program structure.

7. Data Structure - It is a representation of the logical relationship among individual elements ofdata.

8. Software Procedure - It focuses on the processing of each modules individually9. Information Hiding - Modules should be specified and designed so that information contained

within a module is inaccessible to other modules that have no need for such information

3.1.3 Design Heuristic

The main goal of heuristic evaluations is to identify any problems associated with the design of userinterfaces. Usability consultant Jakob Nielsen developed this method on the basis of several years ofexperience in teaching and consulting about usability engineering.

Heuristic evaluations are one of the most informal methods[1] of usability inspection in the field ofhuman-computer interaction. There are many sets of usability design heuristics; they are not mutuallyexclusive and cover many of the same aspects of user interface design.

Quite often, usability problems that are discovered are categorized—often on a numeric scale—accordingto their estimated impact on user performance or acceptance. Often the heuristic evaluation is conductedin the context of use cases (typical user tasks), to provide feedback to the developers on the extent towhich the interface is likely to be compatible with the intended users’ needs and preferences.

The simplicity of heuristic evaluation is beneficial at the early stages of design. This usability inspectionmethod does not require user testing which can be burdensome due to the need for users, a place to testthem and a payment for their time. Heuristic evaluation requires only one expert, reducing the complexityand expended time for evaluation. Most heuristic evaluations can be accomplished in a matter of days.The time required varies with the size of the artifact, its complexity, the purpose of the review, the natureof the usability issues that arise in the review, and the competence of the reviewers. Using heuristicevaluation prior to user testing will reduce the number and severity of design errors discovered by users.Although heuristic evaluation can uncover many major usability issues in a short period of time, acriticism that is often leveled is that results are highly influenced by the knowledge of the expertreviewer(s). This “one-sided” review repeatedly has different results than software performance testing,each type of testing uncovering a different set of problems.

NIELSEN'S HEURISTICS

Jakob Nielsen's heuristics are probably the most-used usability heuristics for user interface design.Nielsen developed the heuristics based on work together with Rolf Molich in 1990.The final set ofheuristics that are still used today were released by Nielsen in 1994. The heuristics as published inNielsen's book Usability Engineering are as follow]

Visibility of system status:The system should always keep users informed about what is going on, through appropriate feedbackwithin reasonable time.



Match between system and the real world:The system should speak the user's language, with words, phrases and concepts familiar to the user, ratherthan system-oriented terms. Follow real-world conventions, making information appear in a natural andlogical order.

User control and freedom:Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leavethe unwanted state without having to go through an extended dialogue. Support undo and redo.

Consistency and standards:Users should not have to wonder whether different words, situations, or actions mean the same thing.Follow platform conventions.

Error prevention:Even better than good error messages is a careful design which prevents a problem from occurring in thefirst place. Either eliminate error-prone conditions or check for them and present users with aconfirmation option before they commit to the action.

Recognition rather than recall:Minimize the user's memory load by making objects, actions, and options visible. The user should nothave to remember information from one part of the dialogue to another. Instructions for use of the systemshould be visible or easily retrievable whenever appropriate.

Flexibility and efficiency of use:Accelerators—unseen by the novice user—may often speed up the interaction for the expert user suchthat the system can cater to both inexperienced and experienced users. Allow users to tailor frequentactions.

Aesthetic and minimalist design:Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit ofinformation in a dialogue competes with the relevant units of information and diminishes their relativevisibility.

Help users recognize, diagnose, and recover from errors:Error messages should be expressed in plain language (no codes), precisely indicate the problem, andconstructively suggest a solution.

Help and documentation:Even though it is better if the system can be used without documentation, it may be necessary to providehelp and documentation. Any such information should be easy to search, focused on the user's task, listconcrete steps to be carried out, and not be too large.

GERHARDT-POWALS’ COGNITIVE ENGINEERING PRINCIPLES

Although Nielsen is considered the expert and field leader in heuristics, Jill Gerhardt-Powals alsodeveloped a set of cognitive principles for enhancing computer performance.]These heuristics, orprinciples, are similar to Nielsen’s heuristics but take a more holistic approach to evaluation. GerhardtPowals’ principle are listed below.



Automate unwanted workload:o free cognitive resources for high-level tasks.o eliminate mental calculations, estimations, comparisons, and unnecessary thinking.

Reduce uncertainty:o display data in a manner that is clear and obvious.

Fuse data:o reduce cognitive load by bringing together lower level data into a higher-level

summation.

Present new information with meaningful aids to interpretation:o use a familiar framework, making it easier to absorb.o use everyday terms, metaphors, etc.

Use names that are conceptually related to function:o Context-dependent.o Attempt to improve recall and recognition.o Group data in consistently meaningful ways to decrease search time.

Limit data-driven tasks:o Reduce the time spent assimilating raw data.o Make appropriate use of color and graphics.

Include in the displays only that information needed by the user at a given time. Provide multiple coding of data when appropriate. Practice judicious redundancy.

3.1.4 Architectural Design

Software architecture is the high level structure of a software system, the discipline of creating suchstructures, and the documentation of these structures. It is the set of structures needed to reason about thesoftware system, and comprises the software elements, the relations between them, and the properties ofboth elements and relations] The architecture of a software system is a metaphor, analogous to thearchitecture of a building

Software architecture choices include specific structural options from possibilities in the design ofsoftware. For example, the systems that controlled the space shuttle launch vehicle have the requirementof being very fast, and very reliable, in principle. Therefore an appropriate real-time computing languagewould be chosen. Similarly, multiple redundant independently produced copies of a program running onindependent hardware and cross-checking results would be a software system architecture choice tosatisfy the need for reliability. Software architecture is about making fundamental structural choiceswhich are costly to change once implemented, i.e., which are used to 'house' the more changeableelements of the program, e.g., an operating system.

Documenting software architecture facilitates communication between stakeholders, captures earlydecisions about the high-level design, and allows reuse of design components between projects.



CHARACTERISTICS

Software architecture exhibits the following:

Multitude of stakeholders: software systems have to cater to a variety of stakeholders such as businessmanagers, owners, users and operators. These stakeholders all have their own concerns with respect to thesystem. Balancing these concerns and demonstrating how they are addressed is part of designing thesystem.This implies that architecture involves dealing with a broad variety of concerns and stakeholders,and has a multidisciplinary nature.

Separation of concerns: the established way for architects to reduce complexity is by separating theconcerns that drive the design. Architecture documentation shows that all stakeholder concerns areaddressed by modeling and describing the architecture from separate points of view associated with thevarious stakeholder concerns. These separate descriptions are called architectural views (see for examplethe 4+1 Architectural View Model).

Quality-driven: classic software design approaches (e.g. Jackson Structured Programming) were drivenby required functionality and the flow of data through the system, but the current insight[3] is that thearchitecture of a software system is more closely related to its quality attributes such as fault-tolerance,backward compatibility, extensibility, reliability, maintainability, availability, security, usability, andother such –ilities. Stakeholder concerns often translate into requirements on these quality attributes,which are variously called non-functional requirements, extra-functional requirements, behavioralrequirements, or quality attribute requirements.

Recurring styles: like building architecture, the software architecture discipline has developed standardways to address recurring concerns. These “standard ways” are called by various names at various levelsof abstraction. Common terms for recurring solutions are architectural style, strategy or tactic, referencearchitecture and architectural pattern.

Conceptual integrity: a term introduced by Fred Brooks in The Mythical Man-Month to denote the ideathat the architecture of a software system represents an overall vision of what it should do and how itshould do it. This vision should be separated from its implementation. The architect assumes the role of“keeper of the vision”, making sure that additions to the system are in line with the architecture, hencepreserving conceptual integrity.

3.1.5 Architectural styles, Architectural Design, Architectural Mapping using Data Flow

This section defines the term “software architecture” as a framework made up of the systemstructures that comprise the software components, their properties, and the relationshipsamong these components. The goal of the architectural model is to allow the software engineerto view and evaluate the system as a whole before moving to component design.

What is Architecture?

The architecture is not the operational software. Rather, it is a representation that enables a softwareengineer to:

(1) Analyze the effectiveness of the design in meeting its stated requirements,

(2) Consider architectural alternatives at a stage when making design changes is still relatively easy, and



(3) Reduce the risks associated with the construction of the software.

Why is Architecture Important?

Representations of software architecture are an enabler for communication between all parties(stakeholders) interested in the development of a computer-based system.

The architecture highlights early design decisions that will have a profound impact on all softwareengineering work that follows and, as important, on the ultimate success of the system as anoperational entity.

Architecture “constitutes a relatively small, intellectually graspable model of how the system isstructured and how its components work together” [BAS03].

Data Design

This section describes data design at both the architectural and component levels. At the architecturelevel, data design is the process of creating a model of the information represented at a high level ofabstraction (using the customer's view of data).

Data Design at the Architectural Level

The challenge is extract useful information from the data environment, particularly when the informationdesired is cross-functional.

To solve this challenge, the business IT community has developed data mining techniques, also calledknowledge discovery in databases (KDD), that navigate through existing databases in an attempt toextract appropriate business-level information.

However, the existence of multiple databases, their different structures, the degree of detail containedwith the databases, and many other factors make data mining difficult within an existing databaseenvironment.

An alternative solution, called a data warehouse, adds on additional layer to the data architecture.

A data warehouse is a separate data environment that is not directly integrated with day-to-dayapplications that encompasses all data used by a business.

In a sense, a data warehouse is a large, independent database that has access to the data that are stored indatabases that serve as the set of applications required by a business.

Data Design at the Component Level

At the component level, data design focuses on specific data structures required to realize the data objectsto be manipulated by a component.

refine data objects and develop a set of data abstractions implement data object attributes as one or more data structures review data structures to ensure that appropriate relationships have been established simplify data structures as requiredSet of principles for data specification:



1. The systematic analysis principles applied to function and behavior should also be applied to data.

2. All data structures and the operations to be performed on each should be identified.

3. A data dictionary should be established and used to define both data and program design.

4. Low level data design decisions should be deferred until late in the design process.

5. The representation of data structure should be known only to those modules that must make direct useof the data contained within the structure.

6. A library of useful data structures and the operations that may be applied to them should bedeveloped.

7. A software design and programming language should support the specification and realization ofabstract data types.

Architectural Styles and Patterns

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 asystem,

(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 analyzingthe known properties of its constituent parts.

An architectural style is a transformation that is imposed on the design of an entire system.

An architectural pattern, like an architectural style, imposes a transformation on the design of anarchitecture.

A pattern differs from a style in a number of fundamental ways:

1. The scope of a pattern is less broad, focusing on one aspect of the architecture rather than thearchitecture in its entirety.

2. A pattern imposes a rule on the architecture, describing how the S/W will handle some aspect of itsfunctionality at the infrastructure level.

3. Architectural patterns tend to address specific behavioral issues within the context of thearchitectural.

A Brief Taxonomy of Architectural Styles

Styles can be categorized as follows:

Data-Centered Architecture

A data store resides at the center of this architecture and is accessed frequently by other components thatupdate, add, delete, or otherwise modify data within the store.



This architecture promotes integrability. Existing components can be changed and new clientcomponents can be added to the architecture without concern about other clients.

Data- flow

Architecture

This architecture is applied when input data are to be transformed through a series of computational ormanipulative components into output data.

A pipe and filter structure has a set of components, called filters, connected by pipes that transmit datafrom one component to the next.



3.1.6 User Interface Design

User interface design requires a good understanding of user needs. There are several phases and processesin the user interface design, some of which are more demanded upon than others, depending on theproject (Note: for the remainder of this section, the word system is used to denote any project whether it isa website, application, or device.)

Functionality requirements gathering – assembling a list of the functionality required by thesystem to accomplish the goals of the project and the potential needs of the users.

User and task analysis – a form of field research, it's the analysis of the potential users of thesystem by studying how they perform the tasks that the design must support, and conductinginterviews to elucidate their goals.[3] Typical questions involve:

o What would the user want the system to do?o How would the system fit in with the user's normal workflow or daily activities?o How technically savvy is the user and what similar systems does the user already use?o What interface look & feel styles appeal to the user?

Information architecture – development of the process and/or information flow of the system (i.e.for phone tree systems, this would be an option tree flowchart and for web sites this would be asite flow that shows the hierarchy of the pages).

Prototyping – development of wireframes, either in the form of paper prototypes or simpleinteractive screens. These prototypes are stripped of all look & feel elements and most content inorder to concentrate on the interface.

Usability inspection – letting an evaluator inspect a user interface. This is generally considered tobe cheaper to implement than usability testing (see step below), and can be used early on in thedevelopment process since it can be used to evaluate prototypes or specifications for the system,which usually can't be tested on users. Some common usability inspection methods includecognitive walkthrough, which focuses the simplicity to accomplish tasks with the system for newusers, heuristic evaluation, in which a set of heuristics are used to identify usability problems inthe UI design, and pluralistic walkthrough, in which a selected group of people step through atask scenario and discuss usability issues.

Usability testing – testing of the prototypes on an actual user—often using a technique calledthink aloud protocol where you ask the user to talk about their thoughts during the experience.User interface design testing allows the designer to understand the reception of the design fromthe viewer’s standpoint, and thus facilitates creating successful applications.

Graphical user interface design – actual look and feel design of the final graphical user interface(GUI). It may be based on the findings developed during the user research, and refined to fix anyusability problems found through the results of testing.]

3.1.7 Interface analysis, Interface Design

User interface design (UID) or user interface engineering is the design of websites, computers,appliances, machines, mobile communication devices, and software applications with the focus on theuser's experience and interaction. The goal of user interface design is to make the user's interaction assimple and efficient as possible, in terms of accomplishing user goals—what is often called user-centereddesign.

Good user interface design facilitates finishing the task at hand without drawing unnecessary attention toitself. Graphic design and typography are utilized to support its usability, influencing how the userperforms certain interactions and improving the aesthetic appeal of the design; design aesthetics may



enhance or detract from the ability of users to use the functions of the interface.[1] The design processmust balance technical functionality and visual elements (e.g., mental model) to create a system that is notonly operational but also usable and adaptable to changing user needs.

Interface design is involved in a wide range of projects from computer systems, to cars, to commercialplanes; all of these projects involve much of the same basic human interactions yet also require someunique skills and knowledge. As a result, designers tend to specialize in certain types of projects and haveskills centered on their expertise, whether that be software design, user research, web design, or industrialdesign.

Interface design deals with the process of developing a method for two (or more) modules in a system toconnect and communicate. These modules can apply to hardware, software or the interface between a userand a machine. An example of a user interface could include a GUI, a control panel for a nuclear powerplant,]or even the cockpit of an aircraft

In systems engineering, all the inputs and outputs of a system, subsystem, and its components are oftenlisted in an interface control document as part of the requirements of the engineering project.

The development of a user interface is a unique field. More information can be found on the subject here:User interface design

3.1.8 Component level Design

Component-based software engineering (CBSE) (also known as component-based development(CBD)) is a branch of software engineering that emphasizes the separation of concerns in respect of thewide-ranging functionality available throughout a given software system. It is a reuse-based approach todefining, implementing and composing loosely coupled independent components into systems. Thispractice aims to bring about an equally wide-ranging degree of benefits in both the short-term and thelong-term for the software itself and for organizations that sponsor such software.

Software engineering practitioners regard components as part of the starting platform for service-orientation. Components play this role, for example, in web services, and more recently, in service-oriented architectures (SOA), whereby a component is converted by the web service into a service andsubsequently inherits further characteristics beyond that of an ordinary component.

Components can produce or consume events and can be used for event-driven architectures (EDA).

3.1.9 Designing Class based components, traditional Components

An individual software component is a software package, a web service, a web resource, or a modulethat encapsulates a set of related functions (or data).

All system processes are placed into separate components so that all of the data and functions inside eachcomponent are semantically related (just as with the contents of classes). Because of this principle, it isoften said that components are modular and cohesive.

With regard to system-wide co-ordination, components communicate with each other via interfaces.When a component offers services to the rest of the system, it adopts a provided interface that specifiesthe services that other components can utilize, and how they can do so. This interface can be seen as asignature of the component - the client does not need to know about the inner workings of the component



(implementation) in order to make use of it. This principle results in components referred to asencapsulated. The UML illustrations within this article represent provided interfaces by a lollipop-symbolattached to the outer edge of the component.

However, when a component needs to use another component in order to function, it adopts a usedinterface that specifies the services that it needs. In the UML illustrations in this article, used interfacesare represented by an open socket symbol attached to the outer edge of the component.

A simple example of several software components - pictured within a hypothetical holiday-reservationsystem represented in UML 2.0.

Another important attribute of components is that they are substitutable, so that a component can replaceanother (at design time or run-time), if the successor component meets the requirements of the initialcomponent (expressed via the interfaces). Consequently, components can be replaced with either anupdated version or an alternative without breaking the system in which the component operates.

As a general rule of thumb for engineers substituting components, component B can immediately replacecomponent A, if component B provides at least what component A provided and uses no more than whatcomponent A used.

Software components often take the form of objects (not classes) or collections of objects (from object-oriented programming), in some binary or textual form, adhering to some interface description language(IDL) so that the component may exist autonomously from other components in a computer.

When a component is to be accessed or shared across execution contexts or network links, techniquessuch as serialization or marshalling are often employed to deliver the component to its destination.

Reusability is an important characteristic of a high-quality software component. Programmers shoulddesign and implement software components in such a way that many different programs can reuse them.Furthermore, component-based usability testing should be considered when software components directlyinteract with users.

It takes significant effort and awareness to write a software component that is effectively reusable. Thecomponent needs to be:



fully documented thoroughly tested

o robust - with comprehensive input-validity checkingo able to pass back appropriate error messages or return codes

designed with an awareness that it will be put to unforeseen uses

UNIT IV TESTING AND IMPLEMENTATION 9Software testing fundamentals-Internal and external views of Testing-white box testing-basis path testing-control structure testing-black box testing- Regression Testing – Unit Testing – Integration Testing –Validation Testing – System Testing And Debugging – Software Implementation Techniques: Codingpractices-Refactoring.

4.1.1 Software testing fundamentals

The entire site is dedicated to the basics of software testing. However, you need to first master the basics

of the basics before you begin. We strongly recommend you to go through the following fundamental

articles if you are just starting the journey into the world of software testing.

Software Quality: Learn how software quality is defined and what it means.

Software quality is the degree of conformance to explicit or implicit requirements and

expectations.

Dimensions of Quality: Learn the dimensions of quality.

Software quality has dimensions such as Accessibility, Compatibility, Concurrency,

Efficiency …

Software Quality Assurance: Learn what it means and what its relationship is with Software

Quality Control.

Software Quality Assurance is a set of activities for ensuring quality in software

engineering processes.

Software Quality Control: Learn what it means and what its relationship is with Software Quality

Assurance.

Software Quality Control is a set of activities for ensuring quality in software products.

SQA and SQC Differences: Learn the differences between Software Quality Assurance and

Software Quality Control.

SQA is process-focused and prevention-oriented but SQC is product-focused and

detection-oriented.

Software Development Life Cycle: Learn what SDLC means and what activities a typical SDLC

model comprises of.



Software Development Life Cycle defines the steps/stages/phases in the building of

software.

Definition of Test: Learn the various definitions of the term ‘test’.

Merriam Webster defines Test as “a critical examination, observation, or evaluation”.

4.1.2 Internal and external views of Testing

Inferences are said to possess internal validity if a causal relation between two variables is properlydemonstrated. A causal inference may be based on a relation when three criteria are satisfied:

1. the "cause" precedes the "effect" in time (temporal precedence),2. the "cause" and the "effect" are related (covariation), and3. there are no plausible alternative explanations for the observed covariation (nonspuriousness)

In scientific experimental settings, researchers often manipulate a variable (the independent variable) tosee what effect it has on a second variable (the dependent variable)] For example, a researcher might, fordifferent experimental groups, manipulate the dosage of a particular drug between groups to see whateffect it has on health. In this example, the researcher wants to make a causal inference, namely, thatdifferent doses of the drug may be held responsible for observed changes or differences. When theresearcher may confidently attribute the observed changes or differences in the dependent variable to theindependent variable, and when he can rule out other explanations (or rival hypotheses), then his causalinference is said to be internally valid

In many cases, however, the magnitude of effects found in the dependent variable may not just depend on

variations in the independent variable, the power of the instruments and statistical procedures used to measure and detect the effects, and the choice of statistical methods (see: Statistical conclusion validity).

Rather, a number of variables or circumstances uncontrolled for (or uncontrollable) may lead to additionalor alternative explanations (a) for the effects found and/or (b) for the magnitude of the effects found.Internal validity, therefore, is more a matter of degree than of either-or, and that is exactly why researchdesigns other than true experiments may also yield results with a high degree of internal validity.

In order to allow for inferences with a high degree of internal validity, precautions may be taken duringthe design of the scientific study. As a rule of thumb, conclusions based on correlations or associationsmay only allow for lesser degrees of internal validity than conclusions drawn on the basis of directmanipulation of the independent variable. And, when viewed only from the perspective of InternalValidity, highly controlled true experimental designs (i.e. with random selection, random assignment toeither the control or experimental groups, reliable instruments, reliable manipulation processes, andsafeguards against confounding factors) may be the "gold standard" of scientific research. By contrast,however, the very strategies employed to control these factors may also limit the generalizability orExternal Validity of the findings.

External validity is the validity of generalized (causal) inferences in scientific research, usually based onexperiments as experimental validity. In other words, it is the extent to which the results of a study can begeneralized to other situations and to other people For example, inferences based on comparativepsychotherapy studies often employ specific samples (e.g. volunteers, highly depressed, no comorbidity).



If psychotherapy is found effective for these sample patients, will it also be effective for non-volunteersor the mildly depressed or patients with concurrent other disorders?

Situation: All situational specifics (e.g. treatment conditions, time, location, lighting, noise,treatment administration, investigator, timing, scope and extent of measurement, etc. etc.) of astudy potentially limit generalizability.

Pre-test effects: If cause-effect relationships can only be found when pre-tests are carried out,then this also limits the generality of the findings.

Post-test effects: If cause-effect relationships can only be found when post-tests are carried out,then this also limits the generality of the findings.

Reactivity (placebo, novelty, and Hawthorne effects): If cause-effect relationships are found theymight not be generalizable to other settings or situations if the effects found only occurred as aneffect of studying the situation.

Rosenthal effects: Inferences about cause-consequence relationships may not be generalizable toother investigators or researchers.

4.1.3 White box testing-basis path testing

In software engineering, basis path testing, or structured testing,[1] is a white box method fordesigning test cases. The method analyzes the control flow graph of a program to find a set of linearlyindependent paths of execution. The method normally uses McCabe' cyclomatic complexity to determinethe number of linearly independent paths and then generates test cases for each path thus obtained.[2]

Basis path testing guarantees complete branch coverage (all CFG edges), but achieves that withoutcovering all possible CFG paths—the latter is usually too costly .Basis path testing has been widely usedand studied

decision-to-decision path, or DD-path, is a path of execution (usually through a flow graphrepresenting a program, such as a flow chart) between two decisions. More recent versions of the conceptalso include the decisions themselves in their own DD-paths.

4.1.4 control structure testing

Control structure testing is a group of white-box testing methods.

1.0 Branch Testing 1.1 Condition Testing 1.2 Data Flow Testing 1.3 Loop Testing

1.0 Branch Testing

also called Decision Testing definition: "For every decision, each branch needs to be executed at least once." shortcoming - ignores implicit paths that result from compound conditionals. Treats a compound conditional as a single statement. (We count each branch taken out of the

decision, regardless which condition lead to the branch.)



This example has two branches to be executed:IF ( a equals b) THENstatement 1ELSEstatement 2END IF

This examples also has just two branches to be executed, despite the compound conditional:IF ( a equals b AND c less than d ) THENstatement 1ELSEstatement 2END IF

This example has four branches to be executed:IF ( a equals b) THENstatement 1ELSEIF ( c equals d) THENstatement 2ELSEstatement 3END IFEND IF

Obvious decision statements are if, for, while, switch. Subtle decisions are return boolean expression, ternary expressions, try-catch. For this course you don't need to write test cases for IOException and OutOfMemory exception.

See this problem and solution.

1.1 Condition Testing

Condition testing is a test construction method that focuses on exercising the logical conditions in aprogram module.

Errors in conditions can be due to:

Boolean operator error Boolean variable error Boolean parenthesis error Relational operator error Arithmetic expression error

definition: "For a compound condition C, the true and false branches of C and every simple condition in Cneed to be executed at least once."

Multiple-condition testing requires that all true-false combinations of simple conditions be exercised atleast once. Therefore, all statements, branches, and conditions are necessarily covered.

1.2 Data Flow Testing



Selects test paths according to the location of definitions and use of variables. This is a somewhatsophisticated technique and is not practical for extensive use. Its use should be targeted to modules withnested if and loop statements.

1.3 Loop Testing

Loops are fundamental to many algorithms and need thorough testing.

There are four different classes of loops: simple, concatenated, nested, and unstructured.

Examples:

Create a set of tests that force the following situations:

Simple Loops, where n is the maximum number of allowable passes through the loop.o Skip loop entirelyo Only one pass through loopo Two passes through loopo m passes through loop where m<n.o (n-1), n, and (n+1) passes through the loop.

Nested Loopso Start with inner loop. Set all other loops to minimum values.o Conduct simple loop testing on inner loop.o Work outwardso Continue until all loops tested.

Concatenated Loopso If independent loops, use simple loop testing.o If dependent, treat as nested loops.

Unstructured loops



o Don't test - redesign.

4.1.5 black box testing

Black-box testing is a method of software testing that examines the functionality of an applicationwithout peering into its internal structures or workings. This method of test can be applied to virtuallyevery level of software testing: unit, integration, system and acceptance. It typically comprises most if notall higher level testing, but can also dominate unit testing as well.

TEST PROCEDURES

Specific knowledge of the application's code/internal structure and programming knowledge in general isnot required. The tester is aware of what the software is supposed to do but is not aware of how it does it.For instance, the tester is aware that a particular input returns a certain, invariable output but is not awareof how the software produces the output in the first place.[1]

Test cases

Test cases are built around specifications and requirements, i.e., what the application is supposed to do.Test cases are generally derived from external descriptions of the software, including specifications,requirements and design parameters. Although the tests used are primarily functional in nature, non-functional tests may also be used. The test designer selects both valid and invalid inputs and determinesthe correct output without any knowledge of the test object's internal structure.

Test design technique

Typical black-box test design techniques include:

Decision table testing All-pairs testing State transition analysis Equivalence partitioning Boundary value analysis Cause–effect graph Error guessing

4.1.6 Regression Testing

Regression testing is a type of software testing that seeks to uncover new software bugs, or regressions,in existing functional and non-functional areas of a system after changes such as enhancements, patchesor configuration changes, have been made to them.

The intent of regression testing is to ensure that changes such as those mentioned above have notintroduced new faults.[1] One of the main reasons for regression testing is to determine whether a changein one part of the software affects other parts of the software

Common methods of regression testing include rerunning previously completed tests and checkingwhether program behavior has changed and whether previously fixed faults have re-emerged. Regressiontesting can be performed to test a system efficiently by systematically selecting the appropriate minimumset of tests needed to adequately cover a particular change.



Contrast with non-regression testing (usually validation-test for a new issue), which aims to verifywhether, after introducing or updating a given software application, the change has had the intendedeffect.

4.1.7 Unit Testing

In computer programming, unit testing is a software testing method by which individual units of sourcecode, sets of one or more computer program modules together with associated control data, usageprocedures, and operating procedures are tested to determine if they are fit for use.[1] Intuitively, one canview a unit as the smallest testable part of an application. In procedural programming, a unit could be anentire module, but it is more commonly an individual function or procedure. In object-orientedprogramming, a unit is often an entire interface, such as a class, but could be an individual method.[2] Unittests are short code fragments[3] created by programmers or occasionally by white box testers during thedevelopment process.

Ideally, each test case is independent from the others. Substitutes such as method stubs, mock objects,[4]

fakes, and test harnesses can be used to assist testing a module in isolation. Unit tests are typically writtenand run by software developers to ensure that code meets its design and behaves as intended.

UNIT TESTING LIMITATIONS

Testing will not catch every error in the program, since it cannot evaluate every execution path in any butthe most trivial programs. The same is true for unit testing. Additionally, unit testing by definition onlytests the functionality of the units themselves. Therefore, it will not catch integration errors or broadersystem-level errors (such as functions performed across multiple units, or non-functional test areas suchas performance). Unit testing should be done in conjunction with other software testing activities, as theycan only show the presence or absence of particular errors; they cannot prove a complete absence oferrors. In order to guarantee correct behavior for every execution path and every possible input, andensure the absence of errors, other techniques are required, namely the application of formal methods toproving that a software component has no unexpected behavior.

Software testing is a combinatorial problem. For example, every boolean decision statement requires atleast two tests: one with an outcome of "true" and one with an outcome of "false". As a result, for everyline of code written, programmers often need 3 to 5 lines of test code.[5] This obviously takes time and itsinvestment may not be worth the effort. There are also many problems that cannot easily be tested at all –for example those that are nondeterministic or involve multiple threads. In addition, code for a unit test islikely to be at least as buggy as the code it is testing. Fred Brooks in The Mythical Man-Month quotes:"Never go to sea with two chronometers; take one or three.Meaning, if two chronometers contradict, howdo you know which one is correct?

Another challenge related to writing the unit tests is the difficulty of setting up realistic and useful tests. Itis necessary to create relevant initial conditions so the part of the application being tested behaves likepart of the complete system. If these initial conditions are not set correctly, the test will not be exercisingthe code in a realistic context, which diminishes the value and accuracy of unit test results

To obtain the intended benefits from unit testing, rigorous discipline is needed throughout the softwaredevelopment process. It is essential to keep careful records not only of the tests that have been performed,



but also of all changes that have been made to the source code of this or any other unit in the software.Use of a version control system is essential. If a later version of the unit fails a particular test that it hadpreviously passed, the version-control software can provide a list of the source code changes (if any) thathave been applied to the unit since that time.

It is also essential to implement a sustainable process for ensuring that test case failures are revieweddaily and addressed immediately. If such a process is not implemented and ingrained into the team'sworkflow, the application will evolve out of sync with the unit test suite, increasing false positives andreducing the effectiveness of the test suite.

Unit testing embedded system software presents a unique challenge: Since the software is beingdeveloped on a different platform than the one it will eventually run on, you cannot readily run a testprogram in the actual deployment environment, as is possible with desktop programs.

4.1.8 Integration Testing

Integration testing (sometimes called integration and testing, abbreviated I&T) is the phase insoftware testing in which individual software modules are combined and tested as a group. It occurs afterunit testing and before validation testing. Integration testing takes as its input modules that have been unittested, groups them in larger aggregates, applies tests defined in an integration test plan to thoseaggregates, and delivers as its output the integrated system ready for system testing.

The purpose of integration testing is to verify functional, performance, and reliability requirements placedon major design items. These "design items", i.e. assemblages (or groups of units), are exercised throughtheir interfaces using black box testing, success and error cases being simulated via appropriate parameterand data inputs. Simulated usage of shared data areas and inter-process communication is tested andindividual subsystems are exercised through their input interface. Test cases are constructed to testwhether all the components within assemblages interact correctly, for example across procedure calls orprocess activations, and this is done after testing individual modules, i.e. unit testing. The overall idea is a"building block" approach, in which verified assemblages are added to a verified base which is then usedto support the integration testing of further assemblages.

Some different types of integration testing are big bang, top-down, and bottom-up. Other IntegrationPatterns are: Collaboration Integration, Backbone Integration, Layer Integration, Client/ServerIntegration, Distributed Services Integration and High-frequency Integration.

[Big Bang

In this approach, all or most of the developed modules are coupled together to form a complete softwaresystem or major part of the system and then used for integration testing. The Big Bang method is veryeffective for saving time in the integration testing process. However, if the test cases and their results arenot recorded properly, the entire integration process will be more complicated and may prevent the testingteam from achieving the goal of integration testing.

A type of Big Bang Integration testing is called Usage Model testing. Usage Model Testing can be usedin both software and hardware integration testing. The basis behind this type of integration testing is torun user-like workloads in integrated user-like environments. In doing the testing in this manner, theenvironment is proofed, while the individual components are proofed indirectly through their use. UsageModel testing takes an optimistic approach to testing, because it expects to have few problems with theindividual components. The strategy relies heavily on the component developers to do the isolated unittesting for their product. The goal of the strategy is to avoid redoing the testing done by the developers,



and instead flesh-out problems caused by the interaction of the components in the environment. Forintegration testing, Usage Model testing can be more efficient and provides better test coverage thantraditional focused functional integration testing. To be more efficient and accurate, care must be used indefining the user-like workloads for creating realistic scenarios in exercising the environment. This givesconfidence that the integrated environment will work as expected for the target customers.

Top-down and Bottom-up

Bottom Up Testing is an approach to integrated testing where the lowest level components are testedfirst, then used to facilitate the testing of higher level components. The process is repeated until thecomponent at the top of the hierarchy is tested.

All the bottom or low-level modules, procedures or functions are integrated and then tested. After theintegration testing of lower level integrated modules, the next level of modules will be formed and can beused for integration testing. This approach is helpful only when all or most of the modules of the samedevelopment level are ready. This method also helps to determine the levels of software developed andmakes it easier to report testing progress in the form of a percentage.

Top Down Testing is an approach to integrated testing where the top integrated modules are tested andthe branch of the module is tested step by step until the end of the related module.

Sandwich Testing is an approach to combine top down testing with bottom up testing.

The main advantage of the Bottom-Up approach is that bugs are more easily found. With Top-Down, it iseasier to find a missing branch link

LIMITATIONS

Any conditions not stated in specified integration tests, outside of the confirmation of the execution ofdesign items, will generally not be tested.

4.1.9 Validation Testing

In software project management, software testing, and software engineering, verification and validation(V&V) is the process of checking that a software system meets specifications and that it fulfills itsintended purpose. It may also be referred to as software quality control. It is normally the responsibility ofsoftware testers as part of the software development lifecycle

Validation checks that the product design satisfies or fits the intended use (high-level checking), i.e., thesoftware meets the user requirements. This is done through dynamic testing and other forms of review.

Verification and validation are not the same thing, although they are often confused. Boehm succinctlyexpressed the difference between

Validation: Are we building the right product? (This is dynamic process for checking and testingthe real product. Software validation always involves with executing the code)[citation needed])

Verification: Are we building the product right? (This is static method for verifying design,code.Software verification is human based checking of documents and files)[citation needed])

According to the Capability Maturity Model



Software Validation: The process of evaluating software during or at the end of the developmentprocess to determine whether it satisfies specified requirements.

Software Verification: The process of evaluating software to determine whether the products of agiven development phase satisfy the conditions imposed at the start of that phaseIn other words,software validation ensures that the product actually meets the user's needs, and that thespecifications were correct in the first place, while software verification is ensuring that theproduct has been built according to the requirements and design specifications. Softwarevalidation ensures that "you built the right thing". Software verification ensures that "you built itright". Software validation confirms that the product, as provided, will fulfill its intended use.

From testing perspective:

Fault – wrong or missing function in the code. Failure – the manifestation of a fault during execution. Malfunction – according to its specification the system does not meet its specified functionality.

RELATED CONCEPTS

Both verification and validation are related to the concepts of quality and of software quality assurance.By themselves, verification and validation do not guarantee software quality; planning, traceability,configuration management and other aspects of software engineering are required.

Within the modeling and simulation (M&S) community, the definitions of validation, verification andaccreditation are similar:

M&S Validation is the process of determining the degree to which a model, simulation, orfederation of models and simulations, and their associated data are accurate representations of thereal world from the perspective of the intended use(s) is the formal certification that a model orsimulation is acceptable to be used for a specific purpose.

Verification is the process of determining that a computer model, simulation, or federation ofmodels and simulations implementations and their associated data accurately represent thedeveloper's conceptual description and specifications.

The definition of M&S validation focuses on the accuracy with which the M&S represents the real-worldintended use(s). Determining the degree of M&S accuracy is required because all M&S areapproximations of reality, and it is usually critical to determine if the degree of approximation isacceptable for the intended use(s). This stands in contrast to software validation.

CLASSIFICATION OF METHODS

In mission-critical software systems, where flawless performance is absolutely necessary, formal methodsmay be used to ensure the correct operation of a system. However, often for non-mission-critical softwaresystems, formal methods prove to be very costly and an alternative method of software V&V must besought out. In such cases, syntactic methods are often used.

Test cases



A test case is a tool used in the process. Test cases may be prepared for software verification and softwarevalidation to determine if the product was built according to the requirements of the user. Other methods,such as reviews, may be used early in the life cycle to provide for software validation.

4.1.10 System Testing And Debugging

Debugging is a methodical process of finding and reducing the number of bugs, or defects, in a computerprogram or a piece of electronic hardware, thus making it behave as expected. Debugging tends to beharder when various subsystems are tightly coupled, as changes in one may cause bugs to emerge inanother.

Numerous books have been written about debugging (see below: Further reading), as it involvesnumerous aspects, including interactive debugging, control flow, integration testing, log files, monitoring(application, system), memory dumps, profiling, Statistical Process Control, and special design tactics toimprove detection while simplifying changes

Normally the first step in debugging is to attempt to reproduce the problem. This can be a non-trivial task,for example as with parallel processes or some unusual software bugs. Also, specific user environmentand usage history can make it difficult to reproduce the problem.

After the bug is reproduced, the input of the program may need to be simplified to make it easier todebug. For example, a bug in a compiler can make it crash when parsing some large source file. However,after simplification of the test case, only few lines from the original source file can be sufficient toreproduce the same crash. Such simplification can be made manually, using a divide-and-conquerapproach. The programmer will try to remove some parts of original test case and check if the problemstill exists. When debugging the problem in a GUI, the programmer can try to skip some user interactionfrom the original problem description and check if remaining actions are sufficient for bugs to appear.

After the test case is sufficiently simplified, a programmer can use a debugger tool to examine programstates (values of variables, plus the call stack) and track down the origin of the problem(s). Alternatively,tracing can be used. In simple cases, tracing is just a few print statements, which output the values ofvariables at certain points of program execution

TECHNIQUES

Print debugging (or tracing) is the act of watching (live or recorded) trace statements, or printstatements, that indicate the flow of execution of a process. This is sometimes called printfdebugging, due to the use of the printf function in C. This kind of debugging was turned on by thecommand TRON in the original versions of the novice-oriented BASIC programming language.TRON stood for, "Trace On." TRON caused the line numbers of each BASIC command line toprint as the program ran.

Remote debugging is the process of debugging a program running on a system different from thedebugger. To start remote debugging, a debugger connects to a remote system over a network.The debugger can then control the execution of the program on the remote system and retrieveinformation about its state.

Post-mortem debugging is debugging of the program after it has already crashed. Relatedtechniques often include various tracing techniques (for example,) and/or analysis of memorydump (or core dump) of the crashed process. The dump of the process could be obtained



automatically by the system (for example, when process has terminated due to an unhandledexception), or by a programmer-inserted instruction, or manually by the interactive user.

"Wolf fence" algorithm: Edward Gauss described this simple but very useful and now famousalgorithm in a 1982 article for communications of the ACM as follows: "There's one wolf inAlaska; how do you find it? First build a fence down the middle of the state, wait for the wolf tohowl, determine which side of the fence it is on. Repeat process on that side only, until you get tothe point where you can see the wolf. This is implemented e.g. in the Git version control systemas the command git bisect, which uses the above algorithm to determine which commitintroduced a particular bug.

Delta Debugging – a technique of automating test case simplification.

4.1.11 Software Implementation Techniques: Coding practices

Best coding practices are a set of informal rules that the software development community has learnedover time which can help improve the quality of software

Many computer programs remain in use for far longer than the original authors ever envisaged(sometimes 40 years or more) so any rules need to facilitate both initial development and subsequentmaintenance and enhancement by people other than the original authors.

In Ninety-ninety rule, Tim Cargill is credited with this explanation as to why programming projects oftenrun late: "The first 90% of the code accounts for the first 90% of the development time. The remaining10% of the code accounts for the other 90% of the development time." Any guidance which can redressthis lack of foresight is worth considering.

The size of a project or program has a significant effect on error rates, programmer productivity, and theamount of management needed

Maintainability. Dependability. Efficiency. Usability.

4.1.12 Refactoring

Refactoring is usually motivated by noticing a code smell. For example the method at hand may be verylong, or it may be a near duplicate of another nearby method. Once recognized, such problems can beaddressed by refactoring the source code, or transforming it into a new form that behaves the same asbefore but that no longer "smells". For a long routine, one or more smaller subroutines can be extracted;or for duplicate routines, the duplication can be removed and replaced with one shared function. Failure toperform refactoring can result in accumulating technical debt.

There are two general categories of benefits to the activity of refactoring.

1. Maintainability. It is easier to fix bugs because the source code is easy to read and the intent of itsauthor is easy to grasp. This might be achieved by reducing large monolithic routines into a set ofindividually concise, well-named, single-purpose methods. It might be achieved by moving amethod to a more appropriate class, or by removing misleading comments.



2. Extensibility. It is easier to extend the capabilities of the application if it uses recognizable designpatterns, and it provides some flexibility where none before may have existed.

Before applying a refactoring to a section of code, a solid set of automatic unit tests is needed. The testsare used to demonstrate that the behavior of the module is correct before the refactoring. If itinadvertently turns out that a test fails, then it's generally best to fix the test first, because otherwise it ishard to distinguish between failures introduced by refactoring and failures that were already there. Afterthe refactoring, the tests are run again to verify the refactoring didn't break the tests. Of course, the testscan never prove that there are no bugs, but the important point is that this process can be cost-effective:good unit tests can catch enough errors to make them worthwhile and to make refactoring safe enough.

The process is then an iterative cycle of making a small program transformation, testing it to ensurecorrectness, and making another small transformation. If at any point a test fails, the last small change isundone and repeated in a different way. Through many small steps the program moves from where it wasto where you want it to be. For this very iterative process to be practical, the tests must run very quickly,or the programmer would have to spend a large fraction of his or her time waiting for the tests to finish.Proponents of extreme programming and other agile methodologies describe this activity as an integralpart of the software development cycle.

Techniques that allow for more abstractiono Encapsulate Field – force code to access the field with getter and setter methodso Generalize Type – create more general types to allow for more code sharingo Replace type-checking code with State/Stratego Replace conditional with polymorphism

Techniques for breaking code apart into more logical pieceso Componentization breaks code down into reusable semantic units that present clear, well-

defined, simple-to-use interfaces.o Extract Class moves part of the code from an existing class into a new class.o Extract Method, to turn part of a larger method into a new method. By breaking down

code in smaller pieces, it is more easily understandable. This is also applicable tofunctions.

Techniques for improving names and location of codeo Move Method or Move Field – move to a more appropriate Class or source fileo Rename Method or Rename Field – changing the name into a new one that better reveals

its purposeo Pull Up – in OOP, move to a superclasso Push Down – in OOP, move to a subclass

UNIT V PROJECT MANAGEMENT 9

Estimation – FP Based, LOC Based, Make/Buy Decision, COCOMO II - Planning – Project Plan,Planning Process, RFP Risk Management – Identification, Projection, RMMM - Scheduling and Tracking–Relationship between people and effort, Task Set & Network, Scheduling, EVA – Process and ProjectMetrics

5.1.1 Estimation – FP Based, LOC Based, Make/Buy Decision, COCOMO II



A function point is a unit of measurement to express the amount of business functionality an informationsystem (as a product) provides to a user. Function points measure software size. The cost (in dollars orhours) of a single unit is calculated from past projects

The risk of "inflation" of the created lines of code, and thus reducing the value of themeasurement system, if developers are incentivized to be more productive. FP advocates refer tothis as measuring the size of the solution instead of the size of the problem.

Lines of Code (LOC) measures reward low level languages because more lines of code areneeded to deliver a similar amount of functionality to a higher level language.[5] C. Jones offers amethod of correcting this in his work.[6]

LOC measures are not useful during early project phases where estimating the number of lines ofcode that will be delivered is challenging. However, Function Points can be derived fromrequirements and therefore are useful in methods such as estimation by proxy.

Loc:

Source lines of code (SLOC), also known as lines of code (LOC), is a software metric used to measurethe size of a computer program by counting the number of lines in the text of the program's source code.SLOC is typically used to predict the amount of effort that will be required to develop a program, as wellas to estimate programming productivity or maintainability once the software is produced

SLOC measures are somewhat controversial, particularly in the way that they are sometimes misused.Experiments have repeatedly confirmed that effort is highly correlated with SLOC, that is, programs withlarger SLOC values take more time to develop. Thus, SLOC can be very effective in estimating effort.However, functionality is less well correlated with SLOC: skilled developers may be able to develop thesame functionality with far less code, so one program with fewer SLOC may exhibit more functionalitythan another similar program. In particular, SLOC is a poor productivity measure of individuals, since adeveloper can develop only a few lines and yet be far more productive in terms of functionality than adeveloper who ends up creating more lines (and generally spending more effort). Good developers maymerge multiple code modules into a single module, improving the system yet appearing to have negativeproductivity because they remove code. Also, especially skilled developers tend to be assigned the mostdifficult tasks, and thus may sometimes appear less "productive" than other developers on a task by thismeasure. Furthermore, inexperienced developers often resort to code duplication, which is highlydiscouraged as it is more bug-prone and costly to maintain, but it results in higher SLOC.

Make/buy decision:

The act of choosing between manufacturing a product in-house or purchasing it from an external supplier.

In a make-or-buy decision, the two most important factors to consider are cost and availability of

production capacity.

An enterprise may decide to purchase the product rather than producing it, if is cheaper to buy than make

or if it does not have sufficient production capacity to produce it in-house. With the phenomenal surge in

global outsourcing over the past decades, the make-or-buy decision is one that managers have to grapple

with very frequently.



investopedia explains 'make-or-buy decision'

Factors that may influence a firm's decision to buy a part rather than produce it internally include lack of

in-house expertise, small volume requirements, desire for multiple sourcing, and the fact that the item

may not be critical to its strategy. Similarly, factors that may tilt a firm towards making an item in-house

include existing idle production capacity, better quality control or proprietary technology that needs to be

protected.

COCOMO II

COnstructive COst MOdel II (COCOMO® II) is a model that allows one to estimate the cost, effort, andschedule when planning a new software development activity. COCOMO® II is the latest majorextension to the original COCOMO® (COCOMO® 81) model published in 1981. It consists of threesubmodels, each one offering increased fidelity the further along one is in the project planning and designprocess. Listed in increasing fidelity, these submodels are called the Applications Composition, EarlyDesign, and Post-architecture models.

COCOMO® II can be used for the following major decision situations

Making investment or other financial decisions involving a software development effort Setting project budgets and schedules as a basis for planning and control Deciding on or negotiating tradeoffs among software cost, schedule, functionality, performance

or quality factors Making software cost and schedule risk management decisions Deciding which parts of a software system to develop, reuse, lease, or purchase Making legacy software inventory decisions: what parts to modify, phase out, outsource, etc Setting mixed investment strategies to improve organization's software capability, via reuse,

tools, process maturity, outsourcing, etc Deciding how to implement a process improvement strategy, such as that provided in the SEI

CMM

The original COCOMO® model was first published by Dr. Barry Boehm in 1981, and reflected thesoftware development practices of the day. In the ensuing decade and a half, software developmenttechniques changed dramatically. These changes included a move away from mainframe overnight batchprocessing to desktop-based real-time turnaround; a greatly increased emphasis on reusing existingsoftware and building new systems using off-the-shelf software components; and spending as much effortto design and manage the software development process as was once spent creating the software product.

These changes and others began to make applying the original COCOMO® model problematic. Thesolution to the problem was to reinvent the model for the 1990s. After several years and the combinedefforts of USC-CSSE, ISR at UC Irvine, and the COCOMO® II Project Affiliate Organizations, the resultis COCOMO® II, a revised cost estimation model reflecting the changes in professional softwaredevelopment practice that have come about since the 1970s. This new, improved COCOMO® is nowready to assist professional software cost estimators for many years to come.

About the Nomenclature



The original model published in 1981 went by the simple name of COCOMO®. This is an acronymderived from the first two letters of each word in the longer phrase COnstructive COst MOdel. The wordconstructive refers to the fact that the model helps an estimator better understand the complexities of thesoftware job to be done, and by its openness permits the estimator to know exactly why the model givesthe estimate it does. Not surprisingly, the new model (composed of all three submodels) was initiallygiven the name COCOMO® 2.0. However, after some confusion in how to designate subsequent releasesof the software implementation of the new model, the name was permanently changed to COCOMO® II.To further avoid confusion, the original COCOMO® model was also then re-designated COCOMO® 81.All references to COCOMO® found in books and literature published before 1995 refer to what is nowcalled COCOMO® 81. Most references to COCOMO® published from 1995 onward refer to what is nowcalled COCOMO® II.

If in examining a reference you are still unsure as to which model is being discussed, there are a fewobvious clues. If in the context of discussing COCOMO® these terms are used: Basic, Intermediate, orDetailed for model names; Organic, Semidetached, or Embedded for development mode, then the modelbeing discussed is COCOMO® 81. However, if the model names mentioned are ApplicationComposition, Early Design, or Post-architecture; or if there is mention of scale factors Precedentedness(PREC), Development Flexibility (FLEX), Architecture/Risk Resolution (RESL), Team Cohesion(TEAM), or Process Maturity (PMAT), then the model being discussed is COCOMO® II.

Intermediate COCOMO computes software development effort as function of program size and a set of"cost drivers" that include subjective assessment of product, hardware, personnel and project attributes.This extension considers a set of four "cost drivers",each with a number of subsidiary attributes:-

Product attributeso Required software reliabilityo Size of application databaseo Complexity of the product

Hardware attributeso Run-time performance constraintso Memory constraintso Volatility of the virtual machine environmento Required turnabout time

Personnel attributeso Analyst capabilityo Software engineering capabilityo Applications experienceo Virtual machine experienceo Programming language experience

Project attributeso Use of software toolso Application of software engineering methodso Required development schedule

Each of the 15 attributes receives a rating on a six-point scale that ranges from "very low" to"extra high" (in importance or value). An effort multiplier from the table below applies to therating. The product of all effort multipliers results in an effort adjustment factor (EAF). Typicalvalues for EAF range from 0.9 to 1.4.

The Intermediate Cocomo formula now takes the form:



E=ai(KLoC)(bi).EAF

where E is the effort applied in person-months, KLoC is the estimated number of thousands of deliveredlines of code for the project, and EAF is the factor calculated above. The coefficient ai and the exponentbi are given in the next table.

Software project ai bi

Organic 3.2 1.05

Semi-detached 3.0 1.12

Embedded 2.8 1.20

The Development time D calculation uses E in the same way as in the Basic COCOMO.

DETAILED COCOMO

Detailed COCOMO incorporates all characteristics of the intermediate version with an assessment of thecost driver's impact on each step (analysis, design, etc.) of the software engineering process.

The detailed model uses different effort multipliers for each cost driver attribute. These Phase Sensitiveeffort multipliers are each to determine the amount of effort required to complete each phase. In detailedcocomo,the whole software is divided in different modules and then we apply COCOMO in differentmodules to estimate effort and then sum the effort

In detailed COCOMO, the effort is calculated as function of program size and a set of cost drivers givenaccording to each phase of software life cycle.

A Detailed project schedule is never static.

The five phases of detailed COCOMO are:-

plan and requirement. system design. detailed design. module code and test. integration and test.

5.1.2 Planning – Project Plan, Planning Process, RFP Risk Management

The Project Planning Phase is the second phase in the project life cycle. It involves creating of a set ofplans to help guide your team through the execution and closure phases of the project.

The plans created during this phase will help you to manage time, cost, quality, change, risk and issues.They will also help you manage staff and external suppliers, to ensure that you deliver the project on timeand within budget.



There are 10 Project Planning steps you need to take to complete the Project Planning Phase efficiently.These steps and the templates needed to perform them, are shown in the following diagram.

Click each link in the diagram below, to learn how these templates will help you to plan projectsefficiently.

Activities

1.Create a

Project Plan

2.Create a

Resource Plan

3.Create a

Financial Plan

4.Create a

Quality Plan

5.Create a

Risk Plan

6.Create a

Acceptance Plan

7.Create a

Communications Plan

8.Create a

Procurement Plan



9.Contract the

Suppliers

10.Perform a

Phase Review

Templates

Project Plan

Resource Plan

Financial Plan

Quality Plan

Risk Plan

Acceptance Plan

Communications Plan

Procurement Plan

Tender ProcessStatement of WorkRequest for InformationRequest for ProposalSupplier ContractTenderRegister

Phase Review Form

The Project Planning Phase is often the most challenging phase for a Project Manager, as you need tomake an educated guess of the staff, resources and equipment needed to complete your project. You mayalso need to plan your communications and procurement activities, as well as contract any 3rd partysuppliers.

In short, you need to create a comprehensive suite of project plans which set out a clear project roadmapahead.

The Project Planning Template suite will help you to do this, by giving you a comprehensive collection ofProject Planning templates.

5.1.3 Identification, Projection, RMMM

a discussion of business uses. Stakeholders (SH) are people or organizations (legal entities such ascompanies, standards bodies) which have a valid interest in the system. They may be affected by it eitherdirectly or indirectly. A major new emphasis in the 1990s was a focus on the identification ofstakeholders. It is increasingly recognized that stakeholders are not limited to the organization employingthe analyst. Other stakeholders will include:



anyone who operates the system (normal and maintenance operators) anyone who benefits from the system (functional, political, financial and social beneficiaries) anyone involved in purchasing or procuring the system. In a mass-market product organization,

product management, marketing and sometimes sales act as surrogate consumers (mass-marketcustomers) to guide development of the product

organizations which regulate aspects of the system (financial, safety, and other regulators) people or organizations opposed to the system (negative stakeholders; see also Misuse case) organizations responsible for systems which interface with the system under design those organizations who integrate horizontally with the organization for whom the analyst is

designing the system

Projection

Risk Projection (aka Risk Estimation)

Attempts to rate each risk in two ways

· The probability that the risk is real · The consequences of the problems associated with the risk, should it occur.

Project planner, along with other managers and technical staff, performs four risk projection activities:

(1) (1) establish a measure that reflects the perceived likelihood of a risk(2) (2) delineate the consequences of the risk(3) (3) estimate the impact of the risk on the project and the product(4) (4) note the overall accuracy of the risk projection so that there will be no misunderstandings.

Developing a Risk TableRisk table provides a project manager with a simple technique for risk projection



igure 2 - Risk Table

Steps in Setting up Risk Table

(1) (1) Project team begins by listing all risks in the first column of the table.Accomplished with the help of the risk item checklists.

(2) (2) Each risk is categorized in the second column(e.g., PS implies a project size risk, BU implies a business risk).

(3) (3) The probability of occurrence of each risk is entered in the next column of the table.The probability value for each risk can be estimated by team members individually.

(4) (4) Individual team members are polled in round-robin fashion until their assessment of riskprobability begins to converge.

Assessing Impact of Each Risk

(1) (1) Each risk component is assessed using the Risk Charcterization Table (Figure 1) and impactcategory is determined.

(2) (2) Categories for each of the four risk components—performance, support, cost, and schedule—areaveraged to determine an overall impact value.

1. 1. A risk that is 100 percent probable is a constraint on the software project.2. 2. The risk table should be implemented as a spreadsheet model. This enables easy

manipulation and sorting of the entries.3. 3. A weighted average can be used if one risk component has more significance for the

project.



(3) (3) Once the first four columns of the risk table have been completed, the table is sorted byprobability and by impact.

· High-probability, high-impact risks percolate to the top of the table, and low-probabilityrisks drop to the bottom.

(4) (4) Project manager studies the resultant sorted table and defines a cutoff line. · cutoff line (drawn horizontally at some point in the table) implies that only risks that lie

above the line will be given further attention. · Risks below the line are re-evaluated to accomplish second-order prioritization. · Risk impact and probability have a distinct influence on management concern.

o o Risk factor with a high impact but a very low probability of occurrence should notabsorb a significant amount of management time.

o o High-impact risks with moderate to high probability and low-impact risks with highprobability should be carried forward into the risk analysis steps that follow.

· All risks that lie above the cutoff line must be managed. · The column labeled RMMM contains a pointer into a Risk Mitigation, Monitoring and

Management Plan

Assessing Risk Impact

· Three factors determine the consequences if a risk occurs:o o Nature of the risk - the problems that are likely if it occurs.

o o e.g., a poorly defined external interface to customer hardware (a technical risk) willpreclude early design and testing and will likely lead to system integration problems latein a project.

o o Scope of a risk - combines the severity with its overall distribution (how much of the projectwill be affected or how many customers are harmed?).

o o Timing of a risk - when and how long the impact will be felt.

· Steps recommended to determine the overall consequences of a risk:

1. Determine the average probability of occurrence value for each risk component.2. Using Figure 1, determine the impact for each component based on the criteria shown.3. Complete the risk table and analyze the results as described in the preceding sections.

Overall risk exposure, RE, determined using:

RE = P x C

P is the probability of occurrence for a riskC is the the cost to the project should the risk occur.

ExampleAssume the software team defines a project risk in the following manner:

Risk identification.



· Only 70 percent of the software components scheduled for reuse will be integrated into theapplication.

· The remaining functionality will have to be custom developed.Risk probability. 80% (likely).

Risk impact.

· 60 reusable software components were planned. · If only 70 percent can be used, 18 components would have to be developed from scratch (in addition

to other custom software that has been scheduled for development). · Since the average component is 100 LOC and local data indicate that the software engineering cost

for each LOC is $14.00, the overall cost (impact) to develop the components would be 18 x 100 x 14= $25,200.

Risk exposure. RE = 0.80 x 25,200 ~ $20,200.

Risk Assessment

· Have established a set of triplets of the form:[ri, li, xi]

whereri is riskli is the likelihood (probability) of the riskxi is the impact of the risk.

· During risk assessment :o o further examine the accuracy of the estimates that were made during risk projectiono o attempt to rank the risks that have been uncoveredo o begin thinking about ways to control and/or avert risks that are likely to occur.

· Must Define a risk referent levelo o performance, cost, support, and schedule represent risk referent levels.o o There is a level for performance degradation, cost overrun, support difficulty, or schedule

slippage (or any combination of the four) that will cause the project to be terminated.o o A risk referent level has a single point, called the referent point or break point, at which

the decision to proceed with the project or terminate it are equally weighted.



· Referent level rarely represented as a smooth line on a graph. · Most cases - a region in which there are areas of uncertainty · Therefore, during risk assessment, perform the following steps:

1. 1. Define the risk referent levels for the project.2. 2. Attempt to develop a relationship between each (ri, li, xi) and each of the referent levels.3. 3. Predict the set of referent points that define a region of termination, bounded by a curve or

areas of uncertainty.4. 4. Try to predict how compound combinations of risks will affect a referent level.

Risk Refinement

· A risk may be stated generally during early stages of project planning. · With time, more is learned about the project and the risk

o o may be possible to refine the risk into a set of more detailed risks · Represent risk in condition-transition-consequence (CTC) format.

o o Stated in the following form:



Given that <condition> then there is concern that (possibly) <consequence>

· Using CTC format for the reuse we can write:Given that all reusable software components must conform to specific design standards and that somedo not conform, then there is concern that (possibly) only 70 percent of the planned reusable modulesmay actually be integrated into the as-built system, resulting in the need to custom engineer theremaining 30 percent of components.

· This general condition can be refined in the following manner:

Subcondition 1. Certain reusable components were developed by a third party with no knowledge ofinternal design standards.

Subcondition 2. The design standard for component interfaces has not been solidified and may notconform to certain existing reusable components.

Subcondition 3. Certain reusable components have been implemented in a language that is notsupported on the target environment.

Risk Mitigation, Monitoring, and Management

Effective strategy must consider three issues:

risk avoidance risk monitoring risk management and contingency planning

· Proactive approach to risk - avoidance strategy. · Develop risk mitigation plan.

· e.g. assume high staff turnover is noted as a project risk, r1. · Based on past history

o o the likelihood, l1, of high turnover is estimated to be 0.70o o the impact, x1, is projected at level 2.o o So… high turnover will have a critical impact on project cost and schedule.

· Develop a strategy to mitigate this risk for reducing turnover. · Possible steps to be taken

o Meet with current staff to determine causes for turnover (e.g., poor working conditions, low pay,competitive job market).

o Mitigate those causes that are under our control before the project starts.o Once the project commences, assume turnover will occur and develop techniques to ensure

continuity when people leave.o Organize project teams so that information about each development activity is widely dispersed.o Define documentation standards and establish mechanisms to be sure that documents are

developed in a timely manner.o Conduct peer reviews of all work (so that more than one person is "up to speed").o Assign a backup staff member for every critical technologist.



· Project manager monitors for likelihood of risk · For high staff turnover, the following factors can be monitored:

o General attitude of team members based on project pressures.o The degree to which the team has jelled.o Interpersonal relationships among team members.o Potential problems with compensation and benefits.o The availability of jobs within the company and outside it.

· Project manager should monitor the effectiveness of risk mitigation steps. · Risk management and contingency planning assumes that mitigation efforts have failed and that the

risk has become a reality.e.g., the project is underway and a number of people announce that they will be leaving.

· Mitigation strategy makes sure: § backup is available § information is documented § knowledge has been dispersed across the team.

· RMMM steps incur additional project coste.g. spending time to "backup" every critical technologist costs money.

· Large project - 30 or 40 risks. · 80 percent of the overall project risk (i.e., 80 percent of the potential for project failure) can be

accounted for by only 20 percent of the identified risks. · Work performed during earlier risk analysis steps will help the planner to determine which of the

risks reside in that 20 percent (e.g., risks that lead to the highest risk exposure).

The RMMM Plan

· Risk Mitigation, Monitoring and Management Plan (RMMM) - documents all work performed aspart of risk analysis and is used by the project manager as part of the overall project plan.

· Alternative to RMMM - risk information sheet (RIS)RIS is maintained using a database system, so that creation and information entry, priority ordering,searches, and other analysis may be accomplished easily.



1. Risk monitoring is a project tracking activity2. Three primary objectives:

1. assess whether predicted risks do, in fact, occur2. ensure that risk aversion steps defined for the risk are being properly applied3. collect information that can be used for future risk analysis.

Problems that occur during a project can be traced to more than one risk.o Another job of risk monitoring is to attempt to allocate origin (what risk(s) caused which

problems throughout the project).



5.1.4 Scheduling and Tracking

Software project scheduling is an activity that distributes estimated effort across the planed projectduration by allocating the effort to specific software engineering tasks.

First, a macroscopic schedule is developed.

---> a detailed schedule is redefined for each entry in the macroscopic schedule.

A schedule evolves over time.

Basic principles guide software project scheduling:

- Compartmentalization

- Interdependency

- Time allocation

- Effort allocation

- Effort validation

- Defined responsibilities

- Defined outcomes

- Defined milestones

There is no single set of tasks that is appropriate for all projects.

An effective software process should define a collection of task sets, each

designed to meet the needs of different types of projects.

A task set is a collection of software engineering work

-> tasks, milestones, and deliverables.

Tasks sets are designed to accommodate different types of projects and different degrees of rigor.

Typical project types:

- Concept Development Projects

- New Application Development Projects

- Application Enhancement Projects



- Application Maintenance Projects

- Reengineering Projects

Degree of Rigor:

- Casual

- Structured

- Strict

- Quick Reaction

Obta

Defining Adaptation Criteria:

-- This is used to determine the recommended degree of rigor.

Eleven criteria are defined for software projects:

- Size of the project

- Number of potential users

- Mission criticality

- Application longevity

- Ease of customer/developer communication

- Maturity of applicable technology

- Performance constraints

- Embedded/non-embedded characteristics

- Project staffing

- Reengineering factors

Individual tasks and subtasks have interdependencies based on their sequence.

A task network is a graphic representation of the task flow for a project.

Figure 7.3 shows a schematic network for a concept development project.

Critical path:



-- the tasks on a critical path must be completed on schedule to make the whole

project on schedule.

Scheduling of a software project does not differ greatly from scheduling of any multitask

engineering effort.

Two project scheduling methods:

- Program Evaluation and Review Technique (PERT)

- Critical Path Method (CPM)

Both methods are driven by information developed in earlier project planning activities:

- Estimates of effort

- A decomposition of product function

- The selection of the appropriate process model

- The selection of project type and task set

Both methods allow a planer to do:

- determine the critical path

- time estimation

- calculate boundary times for each task

Boundary times:

- the earliest time and latest time to begin a task

- the earliest time and latest time to complete a task

- the total float.

5.1.5 Relationship between people and effort, Task Set & Network, Scheduling, EVA



Software engineering handles the relationship between people and effort management for productdevelopment phase. These some points are as follows:-

1. When software size is small single person can handle same project by performing steps likerequirement analysis, designing, code generation, and testing etc.

2. If the project is large additional people are required to complete. the project in stipulated in time itbecome easy to complete project by distributing work among people and get it done as early as possible.

3. The communication path of new comer also increase as time increase and day by day the projectbecome extra complicated. And new customer gets confusion become more after the days by days.

4. It is possible to reduce a desire project completion date by getting more people to same point. Italso possible to expand the completion date by reducing number of resources. And you can mention forthe date of completion.

5. The Putnam norden Rayleigh (PNR) curve is an indication of relationship which exists betweeneffort applied and delivery time for software project.

6. The curve indicate a minimum time value at to which indicates test cost time for delivery as usemove to left to right. It is observed that curved raised non-linearly.

7. It is possible to make delivery fast; the curve rises very sharply to left of td. The pnr curveindicates that project delivery time should not be compressed much behind on td.

8. The number of delivery lines of code are also known as source statements L. Relationship of Lwith effort & development time by equation can be described as

L= P * E1/3 T ¾

Here ‘E’ represents development effort in person months, P is productivity

1. After rearranging the last equation can arrive at an expansion for development effort e.

E = L3/(P3 T4)

E is called as effort expanded over entire life cycle for software development and maintenance

T is the development period in years. And this equation is lead to

E = L3 / (P3 T4) ~ 3.8 Person years.

This shows that by extending last date of project with six month e.g. we can reduce the no of people fromeight to four. The outcome benefit can be gained by using less number of people over longer time toachieve the same objective.

These are all about the relationship between people and effort in software engineering.



Description of People and process management spectrum

The people:-

People management capability maturity model (PM-CMM) has been developed by software engineeringinstitute.

The people management capability maturity model defines following key practice area for softwarepeople:-

Recruiting Selection Performance Training Team / culture development Carrier development

It guides organizations in a creation of mature software process. The various groups are involved for themost needed communication and co-ordination issue required for any effective software. These groupscan be categorized as under:-

1) Stack holder: – Those people who are involved in software process and every software project. Stackholder can be senior manager, project manager practitioner’s customer and end user.

2) Team leader: – The MOI model of leadership state characteristics that define and effective projectmanager motivation, organization and ideas. Successful project leaders use problem solving strategy.

3) Software team:- The people directly involved in a software project are within the software projectmanager scope seven project factor should be considered when planning structure of software engineeringteam these are as follows:-

Difficult of problem to be solved. Size of resultant program. Time that team will stay together. The rigidity of a delivery date. The degree of communication required for project.



4) Agile teams: it is very active team which is a very small highly motivated project team consist of ainformal method which result into overall development simplicity. These are all about the peopledescription.

The Process:-

A comprehensive plan for a software development can be established from a software process framework.A number of a different task based milestone, work product and quality assurance points enables theframeworks activity to be adapted to characteristics of a software project. The frame work activity thatcharacteristics the software processes are applicable to all software projects. The problem is to be selectedprocess model that is appropriate for software to be a engineered by a software team.

The project manager must decide which process mode is appropriate for 1) Customer who has a requestproduct 2) the characteristics of product 3) the project environment.

Once the primary plan is established process decomposition begins a complete plan reflecting work taskrequired to populate to require to framework activities must be created. These are all about process.

Process Decomposition:-

A software team should have extent of adaptability in choosing the software process model which is abest for a project and engineering task. A relatively small project might be a best accomplished usinglinear frequent approach. If very tight time constraints are imposed then problem can be a heavilycompartmentalization RAD model. Project with other characteristics will lead to the selection of a otherprocess model. Once a process model and process framework is decided then generic communicationframework communication, planning, modeling, construction and deployment can be used. It will worksfor a linear model for iterative and incremental model, for evolutionary model and for concurrent orconcurrent assembly models.

Process decomposition commence when the project manager asks how we accomplish the actual activity.Process decomposition is appropriate for the small relatively and a simple project for it. It should be notedwork task s must be adapted to specific need of a project. These are about the process decomposition inthe software engineering for product development activities.

5.1.6 Process and Project Metrics

A software metric is a measure of some property of a piece of software or its specifications. Sincequantitative measurements are essential in all sciences, there is a continuous effort by computer sciencepractitioners and theoreticians to bring similar approaches to software development. The goal is obtainingobjective, reproducible and quantifiable measurements, which may have numerous valuable applicationsin schedule and budget planning, cost estimation, quality assurance testing, software debugging, softwareperformance optimization, and optimal personnel task assignments.

COMMON SOFTWARE MEASUREMENTS

Common software measurements include:

Balanced scorecard Bugs per line of code Code coverage Cohesion Comment density[1]

Connascent software components Coupling Cyclomatic complexity (McCabe's complexity) DSQI (design structure quality index)



Function point analysis Halstead Complexity Instruction path length Maintainability index Number of classes and interfaces Number of lines of code Number of lines of customer requirements Program execution time Program load time Program size (binary) Robert Cecil Martin's software package metrics Weighted Micro Function Points Function Points and Automated Function Points, an Object Management Group standarD CISQ automated quality characteristics measures

LIMITATIONS

As software development is a complex process, with high variance on both methodologies and objectives,it is difficult to define or measure software qualities and quantities and to determine a valid andconcurrent measurement metric, especially when making such a prediction prior to the detail design.Another source of difficulty and debate is in determining which metrics matter, and what they mean.Thepractical utility of software measurements has therefore been limited to the following domains:

Scheduling Software sizing Programming complexity Software development effort estimation Software quality

A specific measurement may target one or more of the above aspects, or the balance between them, forexample as an indicator of team motivation or project performance.

ACCEPTANCE AND PUBLIC OPINION

Some software development practitioners point out that simplistic measurements can cause more harmthan good. Others have noted that metrics have become an integral part of the software developmentprocess. Impact of measurement on programmers psychology have raised concerns for harmful effects toperformance due to stress, performance anxiety, and attempts to cheat the metrics, while others find it tohave positive impact on developers value towards their own work, and prevent them being undervaluedSome argue that the definition of many measurement methodologies are imprecise, and consequently it isoften unclear how tools for computing them arrive at a particular result while others argue that imperfectquantification is better than none (“You can’t control what you can't measure” Evidence shows thatsoftware metrics are being widely used by government agencies, the US military, NASA, IT consultants,academic institutions, and commercial and academic development estimation software.

GLOSSARY



Agile software development-Set of fundamental principles about how software shouldbe developed based on an agile way of working in contrast to previous heavy-handedsoftware development methodologies.

Aggregate planning is an operational activity which does an aggregate plan for theproduction process, in advance of 2 to 18 months, to give an idea to management as towhat quantity of materials and other resources are to be procured and when, so that thetotal cost of operations of the organization is kept to the minimum over that period.

Allocation is the assignment of available resources in an economic way.

Budget -A list of all planned expenses and revenues.

Budgeted cost of work performed (BCWP) -Measures the budgeted cost of work thathas actually been performed, rather than the cost of work scheduled.

Budgeted cost of work scheduled(BCWS)-The approved budget that has been allocatedto complete a scheduled task (or Work Breakdown Structure (WBS) component) during aspecific time period.

Business model -is a profit-producing system that has an important degree ofindependence from the other systems within an enterprise.

Business analysis -The set of tasks, knowledge, and techniques required to identifybusiness needs and determine solutions to business problems. Solutions often include asystems development component, but may also consist of process improvement ororganizational change.

Business operations -Ongoing recurring activities involved in the running of a businessfor the purpose of producing value for the stakeholders. They are contrasted with projectmanagement, and consist of business processes.

Business process -Collection of related, structured activities or tasks that produce aspecific service or product (serve a particular goal) for a particular customer orcustomers. There are three types of business processes: Management processes,Operational processes, and Supporting processes.

Business Process Modeling (BPM) -Tthe activity of representing processes of anenterprise, so that the current ("as is") process may be analyzed and improved in future("to be").

Capability Maturity Model (CMM) -Software engineering is a model of the maturity ofthe capability of certain business processes. A maturity model can be described as astructured collection of elements that describe certain aspects of maturity in anorganization, and aids in the definition and understanding of an organization's processes.



Change control -The procedures used to ensure that changes (normally, but notnecessarily, to IT systems) are introduced in a controlled and coordinated manner.Change control is a major aspect of the broader discipline of change management.

Change management i-s a field of management focused on organizational changes. Itaims to ensure that methods and procedures are used for efficient and prompt handling ofall changes to controlled IT infrastructure, in order to minimize the number and impact ofany related incidents upon service.

Case study is a research method which involves an in-depth, longitudinal examination ofa single instance or event: a case. They provide a systematic way of looking at events,collecting data, analyzing information, and reporting the results.

Certified Associate in Project Management is an entry-level certification for projectpractitioners offered by Project Management Institute.

Communications Log -is an on-going documentation of communication events betweenany identified project stakeholders, managed and collected by the project manager thatdescribes: the sender and receiver of the communication event; where, when and for howlong the communication event elapsed; in what form the communication event tookplace; a summary of what information was communicated; what actions/outcomes shouldbe taken as a result of the communication event; and to what level of priority should theactions/outcomes of the communication event be graded

Constructability is a project management technique to review the construction processesfrom start to finish during pre-construction phrase. It will identify obstacles before aproject is actually built to reduce or prevent error, delays, and cost overrun.

Costsin economics, business, and accounting are the value of money that has been usedup to produce something, and hence is not available for use anymore. In business, thecost may be one of acquisition, in which case the amount of money expended to acquireit is counted as cost.

Cost engineeringis the area of engineering practice where engineering judgment andexperience are used in the application of scientific principles and techniques to problemsof cost estimating, cost control, business planning and management science, profitabilityanalysis, project management, and planning and scheduling."

Construction, in the fields of architecture and civil engineering, is a process that consistsof the building or assembling of infrastructure. Far from being a single activity, largescale construction is a feat of multitasking. Normally the job is managed by the projectmanager and supervised by the construction manager, design engineer, constructionengineer or project architect.

Cost overrun is defined as excess of actual cost over budget.



Critical path method (CPM) is a mathematically based modeling technique forscheduling a set of project activities, used in project management.

Critical chain project management(CCPM) is a method of planning and managingprojects that puts more emphasis on the resources required to execute project tasks.

Dependency in a project network is a link amongst a project's terminal elements.

Dynamic Systems Development Method (DSDM) is a software developmentmethodology originally based upon the Rapid Application Development methodology.DSDM is an iterative and incremental approach that emphasizes continuous userinvolvement.

Durationof a project's terminal element is the number of calendar periods it takes fromthe time the execution of element starts to the moment it is completed.

Deliverable A contractually required work product produced and delivered to a requiredstate. A deliverable may be a document, hardware, software or other tangible product.

Earned schedule (ES) is an extension to earned value management (EVM), whichrenames 2 traditional measures, to indicate clearly they are in units of currency orquantity, not time.

Earned value management (EVM) is a project management technique for measuringproject progress in an objective manner, with a combination of measuring scope,schedule, and cost in a single integrated system.

Effort management is a project management sub discipline for effective and efficientuse of time and resources to perform activities regarding quantity, quality and direction.

Enterprise modeling is the process of understanding an enterprise business andimproving its performance through creation of enterprise models. This includes themodelling of the relevant business domain (usually relatively stable), business processes(usually more volatile), and Information technology

Estimationin project management is the processes of making accurate estimates usingthe appropriate techniques.

Event chain diagram : diagram that show the relationships between events and tasksand how the events affect each other.

Event chain methodology is an uncertainty modeling and schedule network analysistechnique that is focused on identifying and managing events and event chains that affectproject schedules.

Extreme project management(XPM) refers to a method of managing very complex andvery uncertain projects.



Float in a project network is the amount of time that a task in a project network can bedelayed without causing a delay to subsequent tasks and or the project completion date.

Focused improvement in Theory of Constraints is the ensemble of activities aimed atelevating the performance of any system, especially a business system, with respect to itsgoal by eliminating its constraints one by one and by not working on non-constraints.

Fordism, named after Henry Ford, refers to various social theories. It has varying butrelated meanings in different fields, and for Marxist and non-Marxist scholars.

Henry Gantt was an American mechanical engineer and management consultant, whodeveloped the Gantt chart in the 1910s.

Gantt chart is a type of bar chart that illustrates a project schedule. It illustrates the startand finish dates of the terminal elements and summary elements of a project. Terminalelements and summary elements comprise the work breakdown structure of the project.

Goal or objective consists of a projected state of affairs which a person or a system plansor intends to achieve or bring about — a personal or organizational desired end-point insome sort of assumed development. Many people endeavor to reach goals within a finitetime by setting deadlines

Goal setting involves establishing specific, measurable and time targeted objectives

Graphical Evaluation and Review Technique (GERT) is a network analysis techniquethat allows probabilistic treatment of both network logic and activity duration estimated.

Hammock activity is a grouping of subtasks that "hangs" between two end dates it istied to (or the two end-events it is fixed to).

HERMES is a Project Management Method developed by the Swiss Government, basedon the German V-Modell. The first domain of application was software projects.

Integrated Master Plan(IMP) is an event-based, top level plan, consisting of a hierarchyof Program Events.

ISO 10006 is a guidelines for quality management in projects, is an international standarddeveloped by the International Organization for Standardization.

Iterative and Incremental development is a cyclic software development processdeveloped in response to the weaknesses of the waterfall model. It starts with an initialplanning and ends with deployment with the cyclic interaction in between

Kickoff meeting is the first meeting with the project team and the client of the project.



Level of Effort (LOE) is qualified as a support type activity which doesn't lend itself tomeasurement of a discrete accomplishment. Examples of such an activity may be projectbudget accounting, customer liaison, etc.

Linear scheduling method (LSM) is a graphical scheduling method focusing oncontinuous resource utilization in repetitive activities. It is believed that it originallyadopted the idea of Line-Of-Balance method.

Lean manufacturing or lean production, which is often known simply as "Lean", is thepractice of a theory of production that considers the expenditure of resources for anymeans other than the creation of value for the presumed customer to be wasteful, and thusa target for elimination

Managementin business and human organization activity is simply the act of gettingpeople together to accomplish desired goals. Management comprises planning,organizing, staffing, leading or directing, and controlling an organization (a group of oneor more people or entities) or effort for the purpose of accomplishing a goal.

Management process is a process of planning and controlling the performance orexecution of any type of activity.

Management science (MS), is the discipline of using mathematical modeling and otheranalytical methods, to help make better business management decisions.

Megaproject is an extremely large-scale investment project.

Motivationis the set of reasons that prompts one to engage in a particular behavior.

Nonlinear Management(NLM) is a superset of management techniques and strategiesthat allows order to emerge by giving organizations the space to self-organize, evolve andadapt, encompassing Agile, Evolutionary and Lean approaches, as well as many others.

Operations managementis an area of business that is concerned with the production ofgood quality goods and services, and involves the responsibility of ensuring that businessoperations are efficient and effective. It is the management of resources, the distributionof goods and services to customers, and the analysis of queue systems.

Operations Research (OR) is an interdisciplinary branch of applied mathematics andformal science that uses methods such as mathematical modeling, statistics, andalgorithms to arrive at optimal or near optimal solutions to complex problems.

Organization is a social arrangement which pursues collective goals, which controls itsown performance, and which has a boundary separating it from its environment.

Organization development (OD) is a planned, structured, organization-wide effort toincrease the organization's effectiveness and health.



Planning in organizations and public policy is both the organizational process of creatingand maintaining a plan; and the psychological process of thinking about the activitiesrequired to create a desired goal on some scale.

Portfolio in finance is an appropriate mix of or collection of investments held by aninstitution or a private individual.

PRINCE2 : PRINCE2 is a project management methodology. The planning, monitoringand control of all aspects of the project and the motivation of all those involved in it toachieve the project objectives on time and to the specified cost, quality and performance.

Process is an ongoing collection of activities, with an inputs, outputs and the energyrequired to transform inputs to outputs.

Process architecture is the structural design of general process systems and applies tofields such as computers (software, hardware, networks, etc.), business processes(enterprise architecture, policy and procedures, logistics, project management, etc.), andany other process system of varying degrees of complexity.

Process management is the ensemble of activities of planning and monitoring theperformance of a process, especially in the sense of business process, often confused withreengineering.

Product breakdown structure (PBS) in project management is an exhaustive,hierarchical tree structure of components that make up an item, arranged in whole-partrelationship.

Product description in project management is a structured format of presentinginformation about a project product

Program Evaluation and Review Technique (PERT) is a statistical tool, used in projectmanagement, designed to analyze and represent the tasks involved in completing a givenproject.

Program Management is the process of managing multiple ongoing inter-dependentprojects. An example would be that of designing, manufacturing and providing supportinfrastructure for an automobile manufacturer.

Project : A temporary endeavor undertaken to create a unique product, service, or result.

Project accountingIs the practice of creating financial reports specifically designed totrack the financial progress of projects, which can then be used by managers to aidproject management.

Project Cost ManagementA method of managing a project in real-time from theestimating stage to project control; through the use of technology cost, schedule andproductivity is monitored.



Project management : The complete set of tasks, techniques, tools applied duringproject execution'.

Project Management Body of Knowledge(PMBOK): The sum of knowledge within theprofession of project management that is standardized by ISO.

Project management office: The Project management office in a business orprofessional enterprise is the department or group that defines and maintains thestandards of process, generally related to project management, within the organization.The PMO strives to standardize and introduce economies of repetition in the execution ofprojects. The PMO is the source of documentation, guidance and metrics on the practiceof project management and execution.

Project management processis the management process of planning and controlling theperformance or execution of a project.

Project Management Professional is a certificated professional in project management.

Project Management Simulators are computer-based tools used in project managementtraining programs. Usually, project management simulation is a group exercise. Thecomputer-based simulation is an interactive learning activity.

Project management software is a type of software, including scheduling, cost controland budget management, resource allocation, collaboration software, communication,quality management and documentation or administration systems, which are used to dealwith the complexity of large projects.

Project Management Triangleis a model of the constraints of project management.

Project manager : professional in the field of project management. Project managers canhave the responsibility of the planning, execution, and closing of any project, typicallyrelating to construction industry, architecture, computer networking, telecommunicationsor software development.

Project network is a graph (flow chart) depicting the sequence in which a project'sterminal elements are to be completed by showing terminal elements and theirdependencies.

Project planis a formal, approved document used to guide both project execution andproject control. The primary uses of the project plan are to document planningassumptions and decisions, facilitate communication among stakeholders, and documentapproved scope, cost, and schedule baselines. A project plan may be summary ordetailed.

Project planning is part of project management, which relates to the use of schedulessuch as Gantt charts to plan and subsequently report progress within the projectenvironment.



Project stakeholders are those entities within or without an organization which sponsora project or, have an interest or a gain upon a successful completion of a project.

Project teamis the management team leading the project, and provides services to theproject. Projects often bring together a variety number of problems. Stakeholders haveimportant issues with others.

Proportrefers to the combination of the unique skills of an organization’s members forcollective advantage.

Quality can mean a high degree of excellence (“a quality product”), a degree ofexcellence or the lack of it (“work of average quality”), or a property of something (“theaddictive quality of alcohol”).[1] Distinct from the vernacular, the subject of this article isthe business interpretation of quality.

Quality, Cost, Delivery (QCD) as used in lean manufacturing measures a business’sactivity and develops Key performance indicators. QCD analysis often forms a part ofcontinuous improvement programs

Reengineering is radical redesign of an organization's processes, especially its businessprocesses. Rather than organizing a firm into functional specialties (like production,accounting, marketing, etc.) and considering the tasks that each function performs;complete processes from materials acquisition, to production, to marketing anddistribution should be considered. The firm should be re-engineered into a series ofprocesses.

Resources are what is required to carry out a project's tasks. They can be people,equipment, facilities, funding, or anything else capable of definition (usually other thanlabor) required for the completion of a project activity.

Risk is the precise probability of specific eventualities.

Risk management is a management specialism aiming to reduce different risks related toa preselected domain to the level accepted by society. It may refer to numerous types ofthreats caused by environment, technology, humans, organizations and politics.

Risk register is a tool commonly used in project planning and organizational riskassessments.

Schedules in project management consist of a list of a project's terminal elements withintended start and finish dates.

Scientific managementis a theory of management that analyzes and synthesizesworkflow processes, improving labor productivity.

Scope of a project in project management is the sum total of all of its products and theirrequirements or features.



Scope creep refers to uncontrolled changes in a project's scope. This phenomenon canoccur when the scope of a project is not properly defined, documented, or controlled. It isgenerally considered a negative occurrence that is to be avoided.

Scrum is an iterative incremental process of software development commonly used withagile software development. Despite the fact that "Scrum" is not an acronym, somecompanies implementing the process have been known to adhere to an all capital letterexpression of the word, i.e. SCRUM.

Six Sigma is a business management strategy, originally developed by Motorola, thattoday enjoys widespread application in many sectors of industry.

Software engineering is the application of a systematic, disciplined, quantifiableapproach to the development, operation, and maintenance of software.

Systems Development Life Cycle (SDLC) is any logical process used by a systemsanalyst to develop an information system, including requirements, validation, training,and user ownership. An SDLC should result in a high quality system that meets orexceeds customer expectations, within time and cost estimates, works effectively andefficiently in the current and planned Information Technology infrastructure, and is cheapto maintain and cost-effective to enhance.

Systems engineeringis an interdisciplinary field of engineering that focuses on howcomplex engineering projects should be designed and managed.

Task is part of a set of actions which accomplish a job, problem or assignment.

Task analysis is the analysis or a breakdown of exactly how a task is accomplished, suchas what sub-tasks are required

Timelineis a graphical representation of a chronological sequence of events, also referredto as a chronology. It can also mean a schedule of activities, such as a timetable.

Unified Process: The Unified process is a popular iterative and incrementalsoftwaredevelopment process framework. The best-known and extensively documentedrefinement of the Unified Process is the Rational Unified Process (RUP).



QUESTION BANK

Unit 1

Part A

1.A.1 What are the drawbacks of water fall model? Nov 2009

• It is based on customer communication.

• It demands considerable risk assessment

1.A.2 which Process model follows realistic appro ch nd more suitable to large scale system?

Why? Nov 2009

The Spiral is more suitable for large systems. The key characteristic of a Spiral model is riskmanagement at regular stages in the develo ment cycle Formulate plans to: identify software targets,implement the program, and clarify the roject evelopment restrictions

1. Risk analysis: an analytical assessment of selected programs, to consider how to identify andeliminate risk

2. Implementation of the project: the implementation of software development andverification

1.A.3. Give the least two re sons for prototyping is problematic / june 2007Thecomputerbased system can be defined as “a set or an arrangement of elements that are organized to

accomplish some predefined goal by processing information”.

Management . problems

Maintenance problem

Verification is difficult

1.A.4 Differentiate system and computer based system? june 2007

1.A.5 Define software Process ? june 2011



Software process is defined as the structured set of activities that are required to develop thesoftware system.

1.A.6 Mention the drawbacks in Linear Sequential model? june 2011

Not suitable for large-scale projects.

Commitment of developers & customers are needed.

Not appropriate when technical risks are high.

1.A.7 What are the advantages of prototype model? Nov 2006

i. Prototype serves as a basis for deriving system specification.

ii. Design quality can be improved.

iii. System can be maintained easily.

.

iv. Development efforts may get reduced.

v. System usability can be improved.

1.A.8 List atleast four dependency –related risk factors? Nov 2006

Difficult to Understand

Unclear

Teamwork not applicable

Complexity

1. A.9 Explain the software engineering, what do you understand by the term “software” Apr 2008

The application of system tic, disciplined, quantifiable approach to the development, operation &maintenance of softw re (ie)The application of Engineering to Software.

Software.

Software is engineered or developed, it is not manufactured in the classical sense.

Soft are doesn’t wear out.

Although the industry is moving toward component based assembly, most

soft are continues to be custom built.

1. A.10. Discuss software engineering characteristics and components? Apr 2008

Software is engineered,not manufactured.



Software does not wear out.

Most software is custom built rather than being assembled from components

1. A.11Discuss the software process and product metrics with the help of examples and explain the

SDLC. Nov 200Metrics is defined as the degree to which a system component,or process possesses a e

quantifiable reasurable.

1. A.12 What is SRS explain the need of SRS and List the five de irable characteristics of good

SRS document. Nov 2008.

i. Correct – The SRS should be made up to date when appropria r quir ments are identified.ii. Unambiguous – Whenauupdatestherequirementsarecorreclyundrsoodthen only it is possible to write an

unambiguous software.

iii. Complete – To make SRS complete,it shold be specified what a software designer wants to createsoftware.

iv. Consistent – It should be consistent with reference to the functionalities identified. v.

Specific – The requirements sho ld be mentioned specifically.

vi. Traceable – What is the need for mentioned requirement? This should be correctly identifiedi. Evolutionary prototyping. – In this approach of system development, the initial prototype is

prepared and it is then refined through number of stages to final stage.ii. Throw-a ay prototyping – Using this approach a rough practical implementation of the system isproduced. The requirement problems can be identified from this implementation. It is then discarded.System is then developed using some different engineering paradigm.www1.A.14What are the major phases in the water fall model and spiral model? Where is spiral model

beneficial? Apr 2009

Requirement gathering phase in which all requirements are identified.

The deign phase is responsible for creating architectural view of the software.

Direct metrics – It refers to immediately measurable attributes.

Example – Lines of code, execution speed.

Indirect metrics – It refers to the aspects that are not immediately Example– functionality of a program



The implementation phase in which the software design is transformed into coding.

Testing is a kind of phase in which the developed software component is fully tested.

Maintenance is an activity by which the software product can be

maintained.

Requirements

Design

Implementation

Testing

Maintenance

.com

1. A.15 Explain various types of cohesion and coupling in cont xt of oftware design and what

are various debugging approaches? Nov 2010

Data coupling – The data coupling is possible by p r me er passing or data interaction.

Control coupling – The modules share related control ta in control coupling. Common

coupling – The common data or a global ata is shared among modules.

Content coupling – Content co pling occ rs when one module makes use of data or control

information maintained in another mod le.

1.A.16 Compare the relative advantages of the object oriented and function oriented approaches

to software design pr 2011

object is a collection of attributes that act as an aspect, characteristic, quality, ordescriptor of the object

.auupdates

1.A.17 What are the challenges in software? Apr 2012Disadvantages: Soft are is dependent upon the programming language. This method is well

wwwdesignedbutshorter program may get suffered. It does not accommodate non procedural languages. In

early stage of development it is difficult to estimate LOC.

1.A.18 Define software process. Nov 2012

Refer Previous question

1.A.19 What are the umbrella activities of a software process? Apr 2010



Software project tracking and control



Risk management

Software quality assurance

Formal technical reviews

Software configuration management

Work product preparation and production

Reusability management.

Measurement.PART B .com

1.B.1 Which process model leads to software reuse? Explain Nov 2009

Incremental and Iterative Process Models are leads to sof ware r use. Explain these models

• In most engineering disciplines, systems re design d by composition (building system out of

components that have been used in other systems)

• Software engineering has focused on custom evelopment of components

• To achieve better software quality, more quickly, at lower costs, software engineers arebeginning to adopt systematic re se as a design process

Benefits of Reuse auupdates• Increased Reliability

– components . lre dy exercised in working systems• Reduced Process Risk

– less uncertainty in development costs

• Effective Use of Specialists

– reuse components instead of people

• Standards Compliance

– embed standards in reusable components

• Accelerated Development

– avoid custom development and speed up delivery



–

1.B.2 Explain the process model which is useful when staffing is unavailable for complete

implementation Nov 2009

A process model specifies a general process, usually as a set of stages

This model will be suitable for a class of projects

I.e. a model provides generic structure of the process that can be followed by some

projects to achieve their goals

com

1.B.3

SPIRAL

The

task

Usually there are six task regions. In spiral model project n ry point axis is defined.

The task regions are:

Customer communication

Planning

Risk analysis.

Engineering.

Construct and release.

Customer evaluation.

Drawbacks

It is based on customer communication.

It demands considerable risk assessment.

1.B. 4 hat is prototyping? Explain the types of prototyping? Nov 2009

i. Evolutionary prototyping – In this approach of system development,

the initial prototype is prepared and it is then refined through number of

stages to final stage.



ii. Throw-away prototyping – Using this approach a rough practical

implementation of the system is produced. The requirement problems can be identifiedfrom this implementation. It is then discarded. System is then developed using some different engineeringparadigm. Evolutionary prototyping

Objective:

The principal objective of this model is to deliver the working system to the

end-user.

Example -AI systems.

Advantages

.

Fast delivery of the working system.

User is involved while developing the system.

More useful system can be delivered.

Specification, design and implementation work is co-ordin

Problems

Management problems

Maintenance problem

1.B.5 Describe the process model which defines a network of activities? june 2007Refer Previous Questions1.B. 6 Why the “First.system”auupdatesisthrowawaysystem?Explaintheconcept with advantages anddidadvantages ? june 2007• Need to conform is a major source of complexity

• New kid on the block! (rules were already made)

• Perceived as more flexible than hardware or humans

• Result: bewildering diversity of requirements

1.B.7 Draw a system engineering hierarchy diagram and explain the concept? june 2007 -

Computer-based system

- System engineering process



• “Business process” engineering

• Product engineering

.com

1.B.8 Explain the process model that combines the elements of waterfall and iterative fashion? june

2007

Refer Previous question

1.B.9 Explain the various phases of software development life cycle and identify deliverables at each

phase? june 2011

System engineering process follows a waterfall model for the

parallel development of different parts of the system.

Three types of requirements

Abstract functional requirements.

System properties.

Undesirable Characteristics.

System objectives

System requirement problem.



The system design process

Process steps

Partition requirements

Identify sub-systems.

Assign requirements to sub-systems.

Specify sub-system functionality.

Define sub-system interfaces.

Requirement

Definition

.

definition

System

Designcom

Sub-system

Design

System

Integration

System

decommissioning

System

.

evolution

System

Installation

Sub-System development process

After system design it starts.

Involve use of COTS (Commercial-Off-The-Shelf).

www



System Integration

It is the process of putting hardware, software and people together to make a

system.

System Installation

Issues are

Environmental assumptions may be incorrect.

There may be human resistance to the introduction of anew system.

System may have to coexist with alternative systems for some period.

There may arise some physical installation problems (e.g. cabling problem).

Operator training has to be identified.

System evolution

The lifetime of large systems is too long. They must evolve to meet change

requirements. .

The evolution may be costly.com

Existing systems that must be maintained are sometimes c ll d as l gacy systems.

System Decommissioning

Taking the system out of service after its useful lifetime is called as System

Decommissioning.

1.B.10 Explain any four software process models / june 2011 give the advantages and

disadvantages of each. Nov 2006

The software engineers h s five choices for the selection of software process models. The models

Linear Sequential .auupdates Model (LSM)



The Prototype Model (PRM)Inallmodels,core activities are Analysis, Design , Code, Test are common . However their executiondiffers from model to model.

The Rapid Application Development Model (RAD)

The Incremental Model (INS)

The Boehm Spiral Model (BMS)

1.B.11 Discuss waterfall model with its diagrammatic representation ? Nov 2006



Answer: Iterative waterfall model

The iterative waterfall model is as shown in the following figure.

Requirement gathering phase in which all requirements are identified.

The deign phase is responsible for creating architectural view of the

software.

The implementation phase in which the software design is transformed

into coding.

Testing is a kind of phase in which the developed software component is

fully tested.

.

Maintenance is an activity by which the software product can be

maintained.

Requirementscom

Design

Implementation

Testing

Maintenance

1.B.12 What are the requirement issues and management issues with reference to software risk

management? Also list some of the critical areas of risk? Nov 2006

1.B.13 Explain the W ter F ll Software Process Model with neat diagram. Apr 2008

.

www auupdates





. com Requirements analysis anddefinition

Refer Previous question.auupdates 1.B.15 Explain System Engineering Processin detail. Apr 2009

System and software design

Implementation and unit testing

Integration and system testing

Operation and maintenance

The main drawback of the waterfall model is the difficulty of accommodating change after the

process is underway. One phase has to be complete before moving onto the next phase.

1.B.14 Explain the Spir l S/W Process Model with neat diagram. Apr 2008

wwwTheworldviewiscomposed of a set of domains (Di),which can each be a system, orsystem of systems.

WV = {D1,D2,D3,………..,Dn}

Each domain is composed of specific elements (Ej). Di

= {E1, E2, E3,……..Em}

Each element is implemented by specifying the technical components (Ck)that



Software Engineering is about improved ROI (can be Capital and/or Social ROI)

Software production =

development + maintenance

Maintenance costs 60%-80% of all (successful) development costs

– 20% corrective (12%-16% total costs) .

– 30% adaptive (18%-24% total costs)

– 50% perfective (30-40% total costs)

Quicker development is not always prefer ble

– higher up-front costs may defray ownstream costs

– poorly designed/implemented software is a critical cost factor in system cost and delays

1.B.18 Explain the Prototype model Process Model with neat diagram Apr 2010 ReferPrevious question.

1.B.19 Explain the Win-Win Model with neat diagram. Apr 2011• Win-Win Spiral Process Model is a model of a process based on Theory W, which is a

management theory and approach "based on making winners of all of the system's key

stakeholders as a necessary and sufficient condition for project success."

• Identifying the system's stakeholders and their win conditions and

• reconciling win conditions through negotiation to arrive at a mutually satisfactory set of

objectives, constraints, and alternatives for the next level.

• Evaluate Product and Process Alternatives. Resolve Risks

• Define next level of product and process - including partitions

achieve the necessary function for an element. Ej =

{C1,C2,C3………..C4}.

1.B.16 Write short notes on Business Process Engineering overview Apr 2009Business area Analysis

Business System Design

Construction & Engineering

1.B.17Write short notes on Product Engineering overview? Apr 2010



• Validate Product and Process Definitions

• Review, commitment

.

com

1.B.20 Explain the Software Engineering Para igm with neat diagram. Apr 2010

Motivation

What is ‘paradigm’?

Current attitude towards ‘paradigms’

Paradigm as an actor in software engineering

Conclusion

.eople

auupdates

Product

www



Process

Project

1.B.21Explain the Process and design Engineering with neat diagram. Nov2010

- introduction

- Design quality- Design concepts auupdates- The design model

- Design is where customer requirements, business n ds, and t chnical come

together in the formulation of a product or sys m

- The design model provides detail about the softw re d ta structures, architecture,

interfaces, and components

- The design model can be assessed for quality and be improved before code is generated and

tests are conducted

- Does the design contain errors, inconsistencies, or omissions?

- Are there better design alternatives?

- Can the design be implemented within the constraints, schedule, and cost thathave.beenest blished?

- A designer must practice diversification and convergence- The designer selects from design components, component solutions, and .

considerations all

kno ledge available through catalogs, textbooks, and experience

- The designer then chooses the elements from this collection that meet the

requirements defined by requirements engineering and analysis modeling

- Convergence occurs as alternatives are considered and rejected until one

particular configuration of components is chosen

- Software design is an iterative process through which requirements are translated into ablueprint for constructing the softwarewww



- Design begins at a high level of abstraction that can be directly traced back to the data, functional,

and behavioral requirements

1.B.22 Explain the Software Engineering Myths Nov 2011

Software Mythscom

Software Myths- beliefs about software and the process used to build it - can be traced to the earliestdays of computing. Myths have a number of attributes that have made them insidi us. For instance,myths appear to be reasonable statements of fact, they have an intuitive feel, and they are oftenpromulgated by experienced practitioners who “know the.sore”.

Management MythsManagers with software responsibility, like managers in most di cipline , are often under pressure tomaintain budgets, keep schedules from slipping, and improve quality. Like a drowning person whograsps at a straw, a software manag r oft n gra ps at belief in a software myth, If the Belief will lessenthe pressure.

Myth : We already have a book that’s full of stand rds nd procedures for building software. Won’t thatprovide my people with everything they need to know?

Reality : The book of standards may very well exist, but is it used? - Aresoftware practitioners aware of its existence?

- Does it reflect modern software engineering ractice? - Is itcomplete? Is it adaptable?

- Is it streamlined to improve time to delivery while still maintaining a focus on Quality? In manycases, the answer to these entire q estion is no.

Myth : If we get behind sched le, we can add more programmers and catch up (sometimes calledthe Mongoli n horde concept)Reality : Software.development is not a mechanistic process like manufacturing. In the words of Brooks[BRO75]: “Adding people to a late software project makes it later.” At first, this

statementmayseem counterintuitive. However, as new people are added, people who were working mustspend time educating the newcomers, thereby reducing the amount of time spent on productivedevelopment effort

Myth : If e decide to outsource the software project to a third party, I can just relax and let that firmbuild it.

Reality : If an organization does not understand how to manage and control software projectinternally, it will invariably struggle when it out sources software project.

Customer MythsA customer who requests computer software may be a person at the next desk, a technical group downthe hall, the marketing /sales department, or an outside company that has requested software undercontract. In many cases, the customer believes myths about software because



- As design iteration occurs, subsequent refinement leads to design representations at much lower

levels of abstraction

B.E./B.Tech. DEGREE EXAMINATION, NOVEMBER/DECEMBER 2013.

Fifth Semester

Computer Science and Engineering

CS 2301/CS 51/10144 CS 502— SOFTWARE ENGINEERING

(Regulation 2008/2010)

(Common to PTCS 2301 — Software Engineering for B.E. (Part—Time)

Fifth Semester

Computer Science and Engineering — Regulation 2009)

Time: Three hours, Maximum : 100 marks

Answer ALL questions.PART A (10*2=20 marks)1. What is Software Engineering?2. ‘Software doesn't wear out’. Justify3. List two advantages of using traceability tables in the requirements management phase. .4. What are the types of prototypes?5. Develop a CRC model index card for a class ‘Account’ used in a Banking application.6. List two principles of good design.7. What are the levels at which testing is done?8. Define Regression Testing9. Define Software Quality10. What is Risk? Give an example of risk.

PART B - (5 x 16 = 80 marks)11. (a) Compare the following life cycle models based on their distinguishing factors, strengths andweaknesses, — Waterfall Model, R Model, Spiral Model and Formal Methods Model. (Present in theform of table only — use diagrams wherever necessary) (16)

Or



(b) A Coffee Vending Machine dispenses coffee to customers. Customers order coffee by selecting arecipe from a set of recipes. Customers pay for the coffee using coins. Change is given back, if any, to thecustomers. The ‘Service Assistant’ loads ingredients (coffee. powder, milk, sugar, water, chocolate) intothe coffee machine. The ‘Service Assistant’ adds a recipe by indicating the name of the coffee, the unitsof coffee powder, milk, sugar, water and chocolate to be added as well as the cost of the coffee.The Service Assistant can also edit and delete a recipe.(i) Develop the use case diagram for the specification above. (6)(ii) For any two scenarios draw an activity diagram and sequence diagram. . (5 + 5)

12. (a)(i) What is the purpose of feasibility study? (2)(ii) State the ‘inputs and results of the feasibility study.(4)(iii) List any four issues addressed by a feasibility study.(4)(iv) Elaborate the phases involved when carrying out a feasibility study. (6)

Or

(b) (i) Differentiate functional and non-functional requirements. (5)ii). For the requirement given below, identify stakeholders, functional and non-functional requirements(11)

A software is to be built that will control an Automated TellerMachine (ATM). The ATM machine services customers 24 X 7. ATM has a magnetic stripe reader forreading an ATM card, a keyboard and display for interaction with the customer, a slot for depositingenvelopes, a dispenser for cash, a printer for printing receipts and a switch that allows an operator tostart/stop a machine.The ATM services one customer at a time. When a customer inserts an ATM card and enters the personalidentification number (PIN), the details are validated for each transaction. A customer can perform one ormore transactions. Transactions made against each account are recorded so as to ensure validity oftransactions.If PIN is invalid, customer is required to re-enter PIN. beforemaking a transaction, If customer is unable to successfully enter PIN after three tries, card is retained bymachine and customer has to contact bank.The ATM provides the following services to the customer:(1) Withdraw cash in multiples of 100(2) Deposit cash in multiples of 100(3) Transfer amount between any two accounts.(4) Make balance enquiry.(5) Print receipt.

Each of the above transactions must be made within 60 seconds. in case the time exceeds 60 seconds, thenthe transaction is cancelled automatically. Also, if the machine is not used for more than two minutesafter entry of card, the card is retained by the machine.An operator panel with a key-operated switch allows an operator to start and stop the servicing ofcustomers. When the switch is moved to the “off position, the machine will shut down, so that theoperator may remove deposit envelopes and reload the machine with cash, blank receipts, etc. Theoperator is required to verify and enter the total cash on hand before starting the system from this panel.

13.What is system modelling? Explain the process of creating models and the factors that should beconsidered when building models. (16)

or



(b) Tamil Nadu Electricity Board (TNEB) would like to Automate its billing process. Customers applyfor a connection- (domestic/commercial). EB staff take readings and update the system Each customer isrequired to pay charges bi-monthly according to the rates set for the type ofconnection.. Customers can choose to pay either by cash/card. A bill is generated on payment. Monthlyreports are provided to the EB Manager.

(i) Give a name for the system. (1)(ii) Draw the Level — 0 DFD (Context Flow Diagram) (5)(iii) Draw the Level — DFD. (10)

14. (a) Given a set of numbers ‘n’ ,the functioh FindPrime(a[ ],n) prints a number- if it is a prime number.Draw a control flow graph, calculate the cyclomatic complexity and enumerate all paths. State how manytest case-s areneeded to adequately cover the code in terms of branches, decisions and statement?Develop the necessary test cases using sample values for ‘a’ and ‘n’. (16)

Or

(b) (i) What is black box testing? (2)(ii). What is Equivalence Class Partitioning? list rules used to definevalid and invalid equivalence classes. Explain the technique using examples.(7)(iii) What is Boundary Value Analysis? Explain the technique specifying rules and its usage with the helpof an example. (7)15.(a (i Explain the COCOMO model for estimation (8)(ii) State ZIPF’s law. (2)(iii) What is the purpose of Delphi method? State advantages and disadvantages of the method. . (6)

Or

(b) What is Software Configuration Management? Explain various aspects of Configuration Management.(16)

Documents

Software Engineering - Tamilnadu · Concepts of requirements engineering and Analysis ... Roger S. Pressman, “Software Engineering ... The purpose of this chapter is to provide