Shridhar Kuvalekar Deepti Mudegowder Gyo Tanaka
Upcoming SlideShare
Loading in...5
×
 

Shridhar Kuvalekar Deepti Mudegowder Gyo Tanaka

on

  • 1,130 views

 

Statistics

Views

Total Views
1,130
Views on SlideShare
1,130
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Shridhar Kuvalekar Deepti Mudegowder Gyo Tanaka Shridhar Kuvalekar Deepti Mudegowder Gyo Tanaka Presentation Transcript

    • Shridhar Kuvalekar Deepti Mudegowder Gyo Tanaka
      • The Construction phase is where the detailed design for the application is developed as well as the corresponding source code. The goal of this phase is to produce the software and supporting documentation to be transitioned to your user base.
      • It is normal for this phase to contain one or more sub-phases or "iterations" ,especially for large projects.
      • Each iteration provides an opportunity to deliver an increasingly complete solution that can be tested by the customer. The deliverables of each iteration also offer an opportunity to provide feedback that can be incorporated into subsequent iterations.
      • This iterative approach usually gives a good balance of planned, well structured development, and a prudent opportunity to refine previous work and adapt the overall development plan to suit the customer's changing requirements, which inevitably arise on a large project, as do new ideas with the benefit of hindsight.
      • It maximises the likelihood of delivering what the customer ultimately really wants, as opposed to what was initially conceived.
      • To describe the remaining requirements
      • To flesh-out the design of the system
      • To ensure that the system meets the needs of its users and fits into the organization's overall system portfolio
      • To complete component development and testing, including both the software product and its documentation
      • To minimize development costs by optimizing resources
      • To achieve adequate quality as rapidly as possible
      • To develop useful versions of the system (alpha, beta, …) for the user community
      • Revised project schedule, estimate, and risk list from which to manage your project
      • Work closely with modelers. The design of the system is captured in the design models, therefore programmers need to work closely with the modelers to understand the models and to provide relevant feedback regarding the modelers.
      • Document code. Code that isn't worth documenting isn't worth writing. Furthermore, practice shows that developers who write the initial documentation for their code, even if it's only in abbreviated form, are significantly more productive than those that don‘t
      • Write code. If you can't reuse something that already exists, then you're unfortunately forced to write new source code. The code that you write is likely to focus on a variety of aspects, including user interface, business logic, persistence logic, and even system programming.
      • Test code. There is a multitude of testing techniques, such as coverage testing, white-box testing, inheritance-regression testing, class testing, method testing, and class-integration testing (to name a few) that can be used to validate your code.
      • Integrate and package code. You need to integrate and package the work of the entire team, ideally in regular intervals, so that it may all work together. The end result of your integration efforts should be a working build of the system.
      • Reuse of existing components & frameworks:
      • Strategic reuse management - is the process of organizing, monitoring, and directing the efforts of a project team that will lead to reuse at the organization/enterprise-level.
      • Enterprise reuse through components - design by contract — describing the preconditions, post-conditions, and invariants of your operations, classes, and components.
      • Enterprise reuse through frameworks - A framework is a collection of classes and/or components that work together to fulfill a cohesive goal.
      • Software Design Principles
        • Software design principles represent a set of guidelines that helps us to avoid having a bad design.
        • there are 3 important characteristics of a bad design that should be avoided:
      • Rigidity - It is hard to change because every change affects too many other parts of the system.
      • Fragility - When you make a change, unexpected parts of the system break.
      • Immobility - It is hard to reuse in another application because it cannot be disentangled from the current application.
      • Design Patterns: is a general reusable solution to a commonly occurring problem in software design.
      • It is a description or template for how to solve a problem that can be used in many different situations.
      • Types:
      • Creational Design Patterns
      • Behavioral Design Patterns
      • Structural Design Patterns
      • Benefits of using design patterns:
      • They isolate the variability that may exist in the system requirements, making the overall system easier to understand & maintain.
      • Make communication between designers more efficient.
      • Software professionals can immediately picture the high-level design in their heads when they refer the name of the pattern used to solve a particular issue when discussing system design.
      • Framework is an abstraction in which common code providing generic functionality can be selectively overridden or specialized by user code providing specific functionality.
      • They are reusable abstractions of code wrapped in a well-defined API.
      • The code and design reuse capability of frameworks enables higher productivity and shorter time-to-market of application development when compared with traditional software systems development .
      • Types of frameworks:
        • Web application framework: designed to support the development of dynamic websites, Web applications and Web services.
        • JUnit testing framework: is a simple, well designed, testing framework for JAVA.
        • the Microsoft Foundation Classes (MFC) framework, the Object Management Group's (OMG) CORBA and Microsoft's DCOM and COM+ .
      Use of frameworks
      •   Testing can be stated as the process of validating and verifying that a software program/application:
      • meets the business and technical requirements that guided its design and development;
      • works as expected; and
      • can be implemented with the same characteristics.
      • A primary purpose for testing is to detect software failures so that defects may be uncovered and corrected.
      • Functional vs non-functional testing
      • Functional testing refers to tests that verify a specific action or function of the code.
      • Non-functional testing refers to aspects of the software that may not be related to a specific function or user action, such as scalability or security.
      • Functional tests tend to answer the question of "can the user do this" or "does this particular feature work".
      • Non-functional testing tends to answer such questions as "how many people can log in at once", or "how easy is it to hack this software".
      • Testing levels:
      • Tests are frequently grouped by where they are added in the software development process, or by the level of specificity of the test.
      • Unit Testing: refers to tests that verify the functionality of a specific section of code, usually at the function level.
      • Integration testing: is any type of software testing that seeks to verify the interfaces between components against a software design.
      • System testing: tests a completely integrated system to verify that it meets its requirements.
      • System Integration testing: verifies that a system is integrated to any external or third party systems defined in the system requirements.
      • Regression testing: it seeks to uncover software regressions, or old bugs that have come back. Such regressions occur whenever software functionality that was previously working correctly stops working as intended.
      • Acceptance testing
      • Alpha & beta testing
      • For medium – large system development, MHI assigns a system architect, and he/she develops whole system framework and documentations by a system architect before actual development begins.
      • Framework:
      • The purpose of developing framework is to improve the quality of a system:
        • by reducing the amount of codes written by programmers
        • by limiting what programmers can write on their programs
      • It also help MHI increase the easiness of modifications because it can unify the way of the writing codes
      • MHI especially focuses on developing durable “data access object” (DAO).
        • DAO is objects which get, insert, update, and delete data on a database
        • One of the most common way to obtain data via DAO is to execute SQL
        • The problem of SQL is it is difficult to standardize/unify the way of writing the SQL code: the quality of SQL code is totally depended on the ability of each programmer
      • Because of these reasons, MHI often use “Hibernate,” one of the most common DAO framework
      • Hibernate does not require to write SQL to manipulate data on a database because you can specify the conditions by using the method provided by Hibernate class
        • Hibernate automatically converts these conditions into SQL when executing
        • SQL is made based on accessing database
      • Documentation:
      • It explains how to implement the framework to develop the system
      • It also explains what programmers are supposed to do and not to do on the programs they are developing
      • One or two day training program is then provided to all or core programmers, depending on the number, so that they can learn how to use these frameworks
      • During Construction Phase:
      • All technical problems found by programmers or other tech staff are sent to the system architect.
      • The system architect develops the solution for the problem and announces this solution to all programmers and tech staff.
      • The system architect is also responsible for combining all programs together.
      • Thank You!