WHAT IS IT ?

              Computer software is the product that software professionals build and then support over the long term.

                     It encompasses programs that execute within a computer of any size and architecture, content that is presented as the computer programs execute and documents in both hard copy and virtual forms that encompass all forms of electronic media.

 WHO DOES IT ?

                  Software engineers build and support it , and virtually everyone in the industrialized world uses either directly or indirectly.

   WHY IS IT IMPORTANT ?

                  Coz it affects nearly every aspect of our lives and has become pervasive in our commerce , our culture and our activities.

   WHAT ARE THE STEPS ?

                  Software is built like any successful product , by applying on agile , adaptable process that leads to a high quality result that meets the needs of the people who will use the product.

   WHAT IS THE WORK PRODUCT ?

                    From the point of view of a software engineer the work product is the programs , content (data) , and documents that are computer software.

                    From the user’s point of view , the work product is the resultant information that somehow makes the user’s world better.

• Today software takes a dual role.It is both a product and a vehicle for delivering a product
• As a product , it delivers the computing potential embodied by computer hardware or , more broadly , by a network of computers that are accessible by local hardware.
• Whether software resides within a cellular phone or operator inside a mainframe computer , it is an Information Transformer producing , managing , acquiring , modifying , displaying or transmitting information that can be as simple as a single bit or as complex as a multimedia presentation.
• As the vehicle for delivering the product , software acts as the basis for the control of the computer (operating systems) , the communication of information (networks) , and the creation and control of other programs (software tools and environments)
• “SOFTWARE DELIVERS THE MOST IMPORTANT PRODUCT OF OUR TIME”

INFORMATIOn

               It transforms personal data ( Eg., an individual’s financial transactions ) so that the data can be more useful in a local content ; it manages business information to enhance competitiveness ; it provides a gateway to worldwide information networks ( Eg., the internet )

And provides means for acquiring information in all of it forms.

• The role of software has undergone significant change over a span of little more than 50 years.
• Dramatic improvements in hardware performance , profound changes in computing architectures , vast increases in memory and storage capacity , and a wide variety of exotic input and output options have all precipated more sophisticated and complex computer based systems
• Sophistication and complexity can produce dazzling results when a system succeeds , but they can also pose huge problems for those who must build complex systems.
• Today a huge software industry has become a dominant factor in the economies of the industrialized world.
• The lone programmer of an earlier era has been replaced by teams of software specialists , each focusing on one part of the technology required to deliver a complex application.

Software :

1.           Instructions (computer programs) that when executed provide desired features , functions , and performance.

2.           Data structures that enable the programs to adequately manipulate information.

3.           Documents that describe the operarion and use of the programs

.

“SOFTWARE IS LOGICAL RATHER THAN A PHYSICAL SYSTEM ELEMENT”

Characteristics  of  software

  1.   Software is developed or engineered ; it is not manufactured in the classical sense.

SOFTWARE DEVELOPMENT

• High quality is achieved through good design.
• Such problems for software are nonexistent ( or easily corrected )
• It is dependent on people , but people applied and work accompolished is entirely different.
• Software costs are concentrated in engineering.
• Software projects cannot be managed as if they were manufacturing projects.

Hardware manufacturing

• In manufacturing software can introduce quality problems.
• The activities are dependent on people applied and work accompolished is entirely different.

2.                              Software does’nt “wear out”

·        The failure rate as a function of time for hardware

·        The relationship , often called the “bathtub curve” , indicates that hardware exhibits relatively high failure rates early in its life.

FAILURE  CURVES FOR HARDWARE

FAILURE CURVES FOR SOFTWARE

·        Defects one then corrected and failure rate drops to a steady state level for some period of time.

·        As time passes , the failure rate rises again as softwarecomponents suffer from the cumulative affects of dust , vibration , abuse , temperature extremes and other environmental maladies and the simply hardware begins to “Wear out”

·        Software is not susceptible to the environmental maladies that cause hardware to wear out.

·        Undiscovered defects will cause high failure rates early in the life of a program.However , these are corrected and the curve flattens.

·        “Software does’nt wear out but it does deteriorate”

·        During its life software will undergo change.

·        As changes are made,it is likely that errors will be introduced causing the failure rate curve to spike.

·        Before the curve can return to the original steady state failure rate , another change is requested , causing the curve to spike again.Slowly , the minimum failure rate level begins to rise-the software is deteriorating due to change.

·        When  a software component wears out , it is replaced by a spare part.These are no software spare part.

·        Every software failure indicates an error in design or  in the process through which the design was translated into machine – executable code.

3.                                  Although the industry is moving towards component based construction , most software must continue to be custom Built

·        As the engineering discipline evolves , a collection of standard design components is created. Component reuse is a natural part.

·        A software component should be desighned and implemented so that it can be reused in many different programs. Enabling the software engineer to create new applications from reusable parts.

1.2   THE CHANGING NATURE OF SOFTWARE

Seven braod categories of computer software present  continuing challenges for Software Engineer:

1          SYSTEM SOFTWARE:-

                        system software is a collection of programs   written to service other programs.

Eg:    compilers, editors & file management utilities.  

System applications:  Operating system components,drivers,networking  telecommunications.

The system software area is characterised by heavy interaction  with computer hardware;heavy usage of multiusers;concurrent operation that requires scheduling,resource sharing & sophisticated process management;complex data structures & multiple external interfaces.

2          APPLICATION SOFTWARE:-

                        Consists of standalone programs that solve a specific business need.

            In addition to conventional data processing applications,application s/w is used to control business functions in real time.

3          engineering & scientific software:-

                        Formerly characterised by "number crunching" algorithms,engineering and scientific applications range from astrology to volcanology,from automotive stress analysis to space shuttle orbital dynamics from molecular biology to automated manufacturing.

4          EMBEDDED SOFTWARE:-

                        Resides within a product or system and is used to implement and control features and functions for the end-user and for the system itself.

->Embedded s/w can perform limited and esoteric functions.(ex:   keypad control for microwave oven) or provide significant function and control capability(ex:digital functions in an automobile such asfuel control,dashboard displays,braking system).

5          PRODUCT-LINE SOFTWARE:-

                        Designed to provide specific capability for use by many different customers,product line s/w can focus on a limited & esoteric market place or address mass consumer markets (ex:word processing,spread sheets,computer graphics,multimedia,entertainment,data base management personal and business financialapplications).

6          WEB APPLICATIONS:-

                        "Web apps",span a wide array of applications.They can be little more than a set of linked hypertext files that present information using text and limited graphics

ex:E-commerce,B2B applications.

7          ARTIFICIAL INTELLIGENCE SOFTWARE:-

                        AI s/w makes use of nonnumerical algorithms to solve complex problems that are not amenable to computation or straightforward analysis.

Applilcations:Robotics,expert systems,pattern recognition,artificial neural network theorem providing games.

8          UBIQUITOUS COMPUTING:-

                        The rapid groth of wireless networking may soon lead to true distributed computing.The challenge for s/w engineers will be to develop systems and application s/w that will allow small divices,p.c &enterprise system to communicate accross vast networks.

9          NETSOURCING:-

                        The world wide web is rapidly becoming a computong engine as well as a content provider.The challenge for s/w engineers is to architect simple (ex:personal financial planning) & sophisticated applications that provide benifit to targeted end-user markets world-wide.

10        OPEN SOURCE:

                        A growing trend that results in distribution of source code for system applications. (ex:operating systems,database and development environments) so that customers can make local modifications.

            The challenge for SWE is to build source code that is self descriptive,but more importantly,to develop techniques that enable both customers & developers to know what changes have been made and how those changes manifests within the s/w.

          Myths appear to be reasonable statements of fact (sometimes containing element of truth ), they have an intuitive feel and they often promulgated by experience practitioners who “know the score”.

Management Myths :

           Managers with software responsibility  ,like managers in most discipline are often under pressure to maintain budgets , keep schedules from slipping from and improve quality .

MYTH :  We already have a book that’s full of standards and procedures for building  software .Won’t                                                                                             that provide my people with everything they need to know ?

REALITY : The Book of standards may very well exist ,but is it used ? are software practitioners aware of its existence ?  Does it reflest modern software engineering practice ? Is it complete ?Is it Adaptable ? Is it Stremlined to improve time to  delivery while still maintaining a focus on quality ?The answer is NO.

MYTH : If we get behind schedule , we can add more programmes and catch up.

REALITY  : Software development is not a mechanistic process like manufacturing . As new ppl are added   , ppl who were working must spend time educating the newcomers , reducing the time spent on productive development effort.

Customer Myths :

            A Customer who requests computer software may be a person ,a technical group ,the marketing dept. or an outside company.

MYTH  : a General statement of objectives is sufficient to begin writing programs – we can fill in the details later.

REALITY :  Although a comprehensive and stable statement of requirements is not always possible , an     ambiguous statement of objectives is a recipe for disaster.

Unambiguous requirements are developed only through effective and continuous communication between customer and developer

MYTH : Project requirements continually change ,but change can be easily accommodated because software is flexible.

REALITY : It is true software requirements change , but the impact of change varies with the time at which it is introduced

As time passes ,cost impact grows rapidly resources have been committed , a design framework has been established and change can cause upheaval that requires additional resources and major design modification

Practitioner’s Myth :

      Myths that are still believed by software practitioners have been fostered by over 50 years of programming culture. During the early days of software programming was viewed as an art form . Old ways and attitudes die hard.

MYTH : Once we write the program and get it to work , our job is done.

REALITY : Industry data indicate that between 60 and 80% of all effort expended on software will be expended after it is delivered to the customer for the first time.

MYTH : Until I get the rpogramme running ,I have no way of accessing it’s quality.

REALITY : Software reviews are a “quality filter” that have been found to be more effective than testing for finding certain classes of software errors.

MYTH : The only deliverable work product for a successful project is the working programme.

REALITY :A working program is only one part of a software configuration that includes many elements .Documentation provides a foundation for successful engineering and more importantly,guidance for software support.

MYTH : Software engineering will make us create voluminous and unnecessary documentation and will invariably slow us down.

REALITY : Software engineering is not about creating documents .It is about creating quality.Better quality leads to reduced rework and reduced rework results in faster delivery times.

     Many software professional’s  recognize the fallacy of software myths.Reconginition of software realities is the first step toward formulation of practical solutions for software engineering .

1.4       A GENERIC VIEW OF PROCESS

SOFTWARE ENGINEERING – A LAYERED TECHNOLOGY

            Software engineering is the establishment and use of sound engineering.  

        Principles inorder to obtain economically software that is reliable and works efficiently on real machines.

Software engineering.  1) The application of a systematic, disciplined, quantified approach to the development, operation, and maintenance of software i.e., the application of engineering to software.

2) The study of approach as in (1).

v                       Software engineering is a layered technology

v                       An engineering approach rests on an organizational commitment to quality

v                       The bedrock that supports software engineering is the “quality”.

The foundation for SE is the process layer.  SE process is the glue that holds the technology layers together and enables rational and timely development of computer software.

Process defines a framework that must be established for efficient delivery of software engineering technology.

The software process forms the basis for management control of software projects and establishes the context in which technical methods are applied, work products (models, documents, data, reports, forms etc.) are produced, milestones are established, quality is ensured and change is properly managed.

SE METHODS provide the technical “how to’s” for building software.  Methods encompass a broad array of tasks that include communication, requirements analysis, design modeling, program construction, testing and support.

            SE methods rely on a set of basic principles that govern each area of the technology and include modeling activities and other descriptive techniques.

SE TOOLS provide automated or semi-automated support for the process and the methods.  When tools one integrated so that information created by one tool can be used by another, a system for the support of software development, called    computer – aided engineering is established.

1.5                     A   PROCESS FRAMEWORK

• A Process framework establishes the foundation for a complete s/w process by identifying a small number of framework activities that are applicable to all s/w projects regardless of their size or complexity.
• The process framework encompasses a set of umbrella activities are applicable across the entire s/w process.
• Each framework activity is populated by a set of s/w engineering actions- a collection of related tasks that produces a major SE work product.
• Each action is populated with individual work tasks that accomplish some part of the work implied by the action.

Generic process framework-Applicable to s/w projects

Communication: Collaboration with the customer & encompasses requirements gathering & other related   activities.

Planning: It describes the technical tasks to be conducted the risk that are likely, the resources that will be required, the work product to be produced and a work schedule.

Modeling: The creation of models that allows the developer and the customer to better understand s/w requirements and the design that will achieve those requirements.

Construction: This activity combines code generation and the testing i.e., required uncovering errors in the code.

Deployment: The software is delivered to the customer who evaluates the delivered product and provides the feedback based on the evaluation.

            These 5 generic framework activities can be used during the development of small programs, the creation of large web application, & for the engineering of large, computer based systems.

         The details of the s/w process will be quiet different in each case, but the framework remains the same.

                          MODELLING

|                                                                                              |

ANALYSIS                                                             DESIGN   

         |                                                                               |      

Requirements Gathering                                    Data Design

Elaboration                                           Architectural Design                              

Negotiation                                                  Interface Design

Specification                                   Component level Design

Validation                                                                        

(Requirements                                  (Design Specification)

  Specification)

Software Process

The umbrella activities include:

1. Software Project Tracking & Control: allows the s/w team to assess progress against the project plan and take necessary action to maintain schedule.
2. Risk Management: assesses risks that may affect the outcome of the project or the quality of the product.
3. S/w Quality Assurance: defines and conducts the activities required to ensure s/w quality.
4. Formal Technical Reviews: assesses s/w engineering work products in an effort to uncover & remove errors before they are propagated to the next action or activity.
5. Measurement: defines & collects process, project and product measures that assist the team in delivering s/w.
6. Software Configuration Management: manages the effects of change throughout the s/w process.
7. Reusability Management: defines criteria for work product reuse and establishes mechanism to achieve reusable components.
8. Work Product Preparation & Production: activities required to create work products such as models, documents, logs, forms and lists.

Intelligent application of any s/w process model must recognize that adaptation (to the problem, project team, and organizational culture) is essential for success.

1.7  Process patterns

·        The software process can be defined as a collection of patterns that defined a set of activities, actions, work tasks, work products and\or related behaviors required to developed computer software.

·        A process patterns provides us with a templeate –a consistent method for describing an important characteristics of software process

·        By combining software team can construct a process that best meets the needs of a project.

An example process pattern

·        The following abbreviated process pattern describes an approach that may be applicable when stakeholder has a general idea of what must be done, but are unsure of general idea of what must be done, but are unsure of specific software requirement.

Pattern name: Prototyping

Intent: the objective of the pattern is to build a model (a proto type) that can be assessed iteratively by stakeholders in an effort to identify of software requirement

Type: phase pattern

Initial context: the following conditions must be met prior to the initiation of the pattern

Stakeholders have been identified.

1.      A mode of communication between stakeholders and the software team has been established.

2.      The overriding problem to be solved has been identified by stakeholders.

3.      An initial understanding of project scope basic business requirements and project constrains has been developed.

Problem: Requirements are hazy or nonexistent, yet there is clear recognition that there is a problem, and the problem must be addressed with a software solution. Stakeholders are unsure of what they want. i.e., they cannot describe software requirements in any detail.

Solution: a description of the prototyping process is presented

Resulting context:

                                          A software prototype that identifies basic requirements (example: - modes of interaction, computational features, processing functions) is approved by stakeholders.

1. The prototype may evolve thru a series of increments to become the production software (or)
2.  The prototype may be discarded and the production software built using some other process pattern.

Related pattern: cust-communication, iterative design, iterative development, customer assessment, requirements extraction

Known uses/examples: prototyping is recommended when requirements are uncertain

1.8   Process Assessment

Þ Different approach to software process assessment

                           The existence of a software process is no guarantee that software will be delivered on time, that it will need the customer’s needs, or that will exhibit the technical characteristics that will lead to long-term quality characteristics.

            Process patterns must be coupled with solid software engineering practice. In addition, the process itself should be assessed to ensure that it meets a set of basic process criteria that have been shown to be essential for a successful software engineering.     

1.      Standard  CMMI   Assessment method for process improvement

( SCAMPI )  :-- Provides a 5 step process assessment model that Incorporates initiating, diagnosing, establishing, acting, and learning.

2.      CMM -  Based Appraisal for Internal Process Improvement

( CBA – IPI )  :--  Provides a diagnostic technique for assessing the relative maturity of a software organization.

3.      SPICE  (ISO/IEC 15504) Standard defines a set of requirements for software process Assessment. The intent of the standard is to assist orgs to develop any defined software process

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

Software Organizations have exhibited significant shortcomings in their ability to capitalize on the experiences gained from completed projects.

The International Organizations for Standardization (ISO) has developed the ISO : 9001 : 2000  Standard to define the requirements for a quality management system that will serve to produce higher quality products and thereby improve customer satisfaction.

ISO 9001 : 2000  has adopted a “plan-do-check-act”,  cycle that is applied to the quality management elements of a software project.

                  With in a software context “plan” establishes process objectives , activities, and tasks necessary to achieve high quality software and resultant customer satisfaction.

“DO” implements the software process (including both frame works & umbrella activities.

“Check” monitors and measures the process to ensure that all requirements established for quality management have been achieved.

“Act” initiates software process improvement activities that continually work to improve the process.

1.9       PERSONAL & TEAM PROCESS MODELS

PERSONAL SOFTWARE PROCESS :( PSP)

·        Every developer uses some process to build computer s/w. The personal s/w process emphasizes personal measurement of both the work product i.e., produced and the resultant quality of work product.

·        The PSP makes the practitioner responsible for project planning (ex. Estimating & scheduling), and empowers the practitioner to control the quality of all s/w work products that are developed.

·        The PSP process model defines 5 framework activities:

PLANNING:

            Isolates requirements and, based on these, develops both size and resource estimates. All metrics are recorded on a worksheet or template. Finally development tasks are identified and a project schedule is created.

HIGH LEVEL DESIGN:

            An external specification for each component design is created. Prototypes are built when uncertainty exists. All issues are recorded and tracked.

HIGH LEVEL DESIGN REVIEW:

            Formal verification methods are applied to uncover errors in the design. Metrics are maintained for all important tasks and work results.

DEVELOPMENT:

            The component level design is refined and reviewed code is generated, reviewed, compiled, and tested metrics are maintained for all important tasks & work results.

POST MORTEM:

            Using the measures and metrics collected, the effectiveness of the process is determined.

            Measures and metrics should provide guidance for modifying the process to improve its effectiveness.

TEAM SOFTWARE PROCESS (TSP)

• The goal of TSP, is to build a “self directed” project team that organizes itself to produce high quality s/w.
• It defines roles and responsibilities for each team member, track quantitative project data.
• Identifies a team process that is appropriate for the project.
• A strategy for implementing the process.
• Defines local standards that are applicable to the team’s SE work.
• Continually assesses risk that reacts to it.
• Tracks & manages, & reports project status.
• TSP defines the following framework activities:

Launch high-level design, implementation, integration and test, and postmortem.

• TSP makes use of a wide variety of scripts, forms & standards that serve to guide team members in their work.

SCRIPT: Defines specific process activities and more detailed work functions that are part of the team process.

PROCESS ACTIVITIES: Project launch, design, implementation, integration, testing, postmortem.

WORK FUNCTIONS: Development, planning, requirements development s/w configuration mgmt., unit test.

Each project is “launched” using a sequence of tasks that enables the team to establish a solid basis for starting the project.

The following is a LAUNCH SCRIPT (outline only):-

• Review project objectives with mgmt. and agree on and document team goals.
• Establish team roles.
• Define the team’s development process.
• Make a quality plan and set quality targets.
• Plan for the needed support facilities.
• Produce an overall development strategy.
• Make a development plan for the entire project.
• Make detailed plans for each engineer for the next phase.
• Merge the individual plans into a team plan.
• Rebalance team workload to achieve a minimum overall schedule.