Friday, March 21, 2014

Formal Specification

  • Formal software specifications are mathematical entities and may be analyzed using mathematical methods. Specification consistency and completeness can be proved mathematically.
  • Formal specifications may be automatically processed. Software tools can be used to build programs from formal specifications.
  • The development of a formal specification provides insights into and an understanding of the software requirements and the software design.

problems with formal development methods

  • Many software engineers have not been trained in the techniques required to develop formal specifications.
  • Customers may be unwilling to fund development activities that they cannot easily monitor.
  • Software management is inherently conservative and is unwilling to adopt new techniques for which payoff is not obvious.
  • Most of the effort in specification research has been concerned with the development of languages and their theoretical aspectsrather than tools and methods.


     Rapid Application Development (RAD) is an incremental software development process model that emphasizes an extremely short development cycle.If requirements are well understood and project scope is constrained, the RAD process enables a development team to create a ‘fully functional system’ within very short time periods (eg. 60 to 90 days).

  • Business modelling - The information flow in a business system considering its functionality.
  • Data Modelling - The information flow defined as part of the business modelling phase is refined into a set of data objects that are needed to support the business
  • Process Modelling - The data objects defined in the data modelling phase are transformed to achieve the information flow necessary to implement business functions.
  • Application generation - RAD assumes the use of 4GL or visual tools to generate the system using reusable components.
  • Testing and turnover - New components must be tested and all interfaces must be fully exercised.

Problems with the RAD model

  • RAD requires sufficient human resources to create right number of RAD teams.
  • RAD requires developers and customers who are committed to the rapid-fire activities necessary to get a system completed in a much abbreviated time frame.
  • If a system cannot be properly modularized, building the components necessary for RAD will be problematic.
  • RAD is not applicable when technical risks are high. This occurs when a new application makes heavy use of new technology or when the new software requires a high degree of interoperability with existing computer programs.
   Extreme Programming (XP) is the most widely used Agile Process model. XP uses an object oriented approach as its development paradigm. XP encompasses a set of rules and practices that occur within the context of four framework activities : planning, design , coding and testing.


Planning

  • Begins with a set of stories (scenarios).
  • Each story written by the customer is assigned a value depending on its priority.
  • The members of the XP team assess each story and assigned a cost measured in development weeks.
  • If a story has more that three weeks to develop the customer is asked to split it.
  • New stories can add any time.
  • Customers and XP team work together to decide how to group stories for next increment.
  • AS development work proceeds, the customers can add stories, split stories and eliminate them.
  • The XP team then reconsiders all remaining releases and modify its plan accordingly.
Design

  • A simple design is preferred.
  • Design only consider the given stories.
  • Extra functionality discouraged.
  • Identify the object oriented classes that are relavant to the current system.
  • The output of the design process is a set of CRC ( Class Responsibility Collaborator) cards.
Coding

  • XP recommends developing a series of unit tests for each of the story.
  • Once the code is complete, units should be unit tested.
  • Pair programming – two people work together at one computer.
Testing

  • The unit tests that has been created in the coding stage should be implemented using a framework that can be implemented.
  • This enables regression testing.
  • Integration and validation can occur on a daily basis.
  • This provides the XP team with a continual indication of the progress and also raise flags early if things are going wrong.
  • Acceptance tests are derived from user stories that have been implemented as parts of the software release.




      Agile software engineering combines a philosophy and a set of development guidelines. The philosophy encourages the customer satisfaction and early incremental delivery of software; small and highly motivated software teams, informal methods, minimal software engineering work products, and overall development simplicity. The development guidelines stress delivery and active and continuous communication between developers and customers.

       An agile process adapt incrementally. To accomplish incremental adaptation, an agile team requires customer feedback. An effective tool to get customer feedback is an operational prototype or a portion of an operational system. Software increments must be delivered in short time periods so that the adaptation keep pace with the change This iterative approach enables the customer to evaluate the software increment regularly and provide necessary feedback to the software team.

This model is an evolutionary software process model that couples the iterative nature of prototyping with the controlled and systematic aspects of the linear sequential model. Using the spiral model software is developed in a series of incremental releases. During early iterations, the incremental release might be a paper model or prototype.

The spiral model is divided into four main task regions

  • Determine goals, alternatives,constraints
  • Evaluate alternatives and risks
  • Develop and test
  • Plan

The Unified Process or Rational Unified Process (RUP) is a framework for object oriented software engineering using UML. This is a use-case driven, architecture centric, iterative and incremental software development model.


Inception Phase

The Inception Phase of UP includes both customer communication and planning activities. By collaborating with the customer and end-users, business requirements for the software are identified, a rough architecture for the system is proposed, and a plan for the iterative, incremental nature of the project is developed.

Elaboration Phase

The Elaboration Phase encompasses the planning and modeling activities of the generic process model. Elaboration refines and expands the primary use-cases that were developed as part of the inception phase and expands the architectural representation to include five different views of the software – the use-case model, the analysis model, the design model, the implementation model and the deployment model.

Construction Phase

The construction phase of the UP is identical to the construction activity defined in the generic software process. Using the architectural model as input, the construction phase develops or acquires the software components that will make each usecase operational for end-users. As components are developed unit tests are designed and executed for each component. Integration testing and acceptance testing are carried out using use-cases to derive required test cases.

Transition Phase

The Transition Phase of the UP encompasses the later stages of the generic construction activity and the first part of the generic deployment activity. Software is given to end-users for beta testing. The software team creates necessary support information (user manual, installation manual etc.). At the end of transition phase, the software increment becomes a usable software release.

Production Phase

The production phase of the UP coincides with the deployment activity of the generic process. During this phase, the on going use of the software is monitored, support for operating environment is provided, and defect reports and requests for change are submitted and evaluated.

It is likely that at the same time the construction, transition and production phases are being conducted, work may have already begun on the next software increment. This means that the unified process do not occur in a sequence, but rather with staggered concurrency.
  • Emphasizes the design and construction of computer based systems using software “components”.
  • The process relies on reusable software components.
  • Similar to the characteristics of the spiral model.

  • Requirement specification and validation steps are similar to the other processes.

    Component Analysis

    During this stage try to find the software components need for the implementation once the requirements are specified.

    Requirements Modification

    Analyze the discovered software components to find out whether it is able to achieve the specified requirements.

    System Design with Reuse

    The frame work of the system is designed to get the maximum use of discovered components. New software may have to design if the reusable components are not available.

    Development and integration

    Software that cannot be discovered is developed, and the reusable components are integrated to create the new system. The integration process, may be part of the development process rather than a separate activity.


    Copyright © Software Engineering Fundamentals | Powered by Blogger
    Design by N.Design Studio | Blogger Theme by NewBloggerThemes.com