Download Characteristics of software and Difference between program and software and more Lecture notes Journalism in PDF only on Docsity!
(1) Software & Software Engineering
Software:
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 descriptive information in both hard copy and virtual forms that encompass virtually any electronic media.
Characteristics of software:
[1] Software is developed or engineered; it is not manufactured in the classical sense:
Although some similarities exist between software development and hardware manufacturing, but few activities are fundamentally different. In both activities, high quality is achieved through good design, but the manufacturing phase for hardware can introduce quality problems than software.
[2] Software doesn’t ―wear out.‖
Hardware components suffer from the growing effects of dust, vibration, abuse, temperature extremes, and many other environmental maladies. Stated simply, the hardware begins to wear out. Software is not susceptible to the environmental maladies that cause hardware to wear out. In theory, therefore, the failure rate curve for software should take the form of the ―idealized curve‖. When a hardware component wears out, it is replaced by a spare part. There are no software spare parts. Every software failure indicates an error in design or in the process through which design was translated into machine executable code. Therefore, the software maintenance tasks that accommodate requests for change involve considerably more complexity than hardware maintenance. However, the implication is clear—software doesn’t wear out. But it does deteriorate.
Hardware Failure curve Software Failure curve
[3] Although the industry is moving toward component-based construction, most software continues to be custom built.
A software component should be designed and implemented so that it can be reused in many different programs.
Modern reusable components encapsulate both data and the processing that is applied to the data, enabling the software engineer to create new applications from reusable parts. In the hardware world, component reuse is a natural part of the engineering process
Difference between program and software
Program Software
- Small in size.
- Authors himself is user-soul.
- Single developer.
- Adopt development.
- Lack proper interface.
- Large proper documentation.
Software Myths:
- Large in size.
- Large number.
- Team developer.
- Systematic development.
- Well define interface.
- Well documented
Software myths are beliefs about software and the process used to build it.
(1) Management Myths:
Myth 1: 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 reflect modern software engineering practice? Is it complete? Is it adaptable? Is it streamlined to improve time-to-delivery while still maintaining a focus on quality? In many cases, the answer to all of these questions is no. Myth 2: If we get behind schedule, we can add more programmers and catch up. Reality:
Software development is not a mechanistic process like manufacturing. As new people are added, people who were working must spend time educating the newcomers, thereby reducing the amount of time spent on productive development effort. People can be added but only in a planned and well-coordinated manner. Myth 3: If I decide to outsource the software project to a third party, I can just relax and let that firm build it. Reality: If an organization does not understand how to manage and control software projects internally, it will invariably struggle when it outsources software projects.
Myth 4: 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 a quality product. Better quality leads to reduced rework. And reduced rework results in faster delivery times.
Software Engineering :
Software Engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software.
A Layered Technology:
A Waterfall Process Model
The waterfall model, sometimes called the classic life cycle, suggests a systematic, sequential approach to software development that begins with customer specification of requirements and progresses through planning, modeling, construction, and deployment, culminating in ongoing support of the completed software.
Limitations :
Figure: Waterfall Model
The nature of the requirements will not change very much during development; during evolution. The model implies that you should attempt to complete a given stage before moving on to the next stage. Does not account for the fact that requirements constantly change. It also means that customers cannot use anything until the entire system is complete. The model implies that once the product is finished, everything else is maintenance. Surprises at the end are very expensive Some teams sit ideal for other teams to finish Therefore, this model is only appropriate when the requirements are well-understood and changes will be fairly limited during the design process.
When to use waterfall model?
Requirements are very well known, clear and fixed Product definition is stable Technology is understood There are no ambiguous requirements Ample resources with required expertise are available freely The project is short
(3) RAD (Rapid Application Development) Process Model
It is a type of incremental model. In RAD model the components or functions are developed in parallel as if they were mini projects. The developments are time boxed, delivered and then assembled into a working prototype. This can quickly give the customer something to see and use and to provide feedback regarding the delivery and their requirements.
Figure: Rapid Application Development Model
Advantages:
Reduced development time. Increases reusability of components Quick initial reviews occur Encourages customer feedback Integration from very beginning solves a lot of integration issues.
Disadvantages:
For large but scalable projects RAD requires sufficient human resources. Projects fail if developers and customers are not committed in a much shortened time-frame. Problematic if system cannot be modularized. Not appropriate when technical risks are high (heavy use of new technology).
When to use RAD model?
RAD should be used when there is a need to create a system that can be modularized in 2-3 months of time. It should be used if there’s high availability of designers for modeling and the budget is high enough to afford their cost along with the cost of automated code generating tools. RAD SDLC model should be chosen only if resources with high business knowledge are available and there is a need to produce the system in a short span of time (2-3 months).
(4) Prototype process model
The basic idea here is that instead of freezing the requirements before a design or coding can proceed, a throwaway prototype is built to understand the requirements. This prototype is developed based on the currently known requirements. By using this prototype, the client can get an ―actual feel‖ of the system, since the interactions with prototype can enable the client to better understand the requirements of the desired system. Prototyping is an attractive idea for complicated and large systems for which there is no manual process or existing system to help determining the requirements. The prototype are usually not complete systems and many of the details are not built in the prototype. The goal is to provide a system with overall functionality.
Advantages:
Figure: Prototype Model
Users are actively involved in the development Since in this methodology a working model of the system is provided, the users get a better understanding of the system being developed. Errors can be detected much earlier. Quicker user feedback is available leading to better solutions. Missing functionality can be identified easily Confusing or difficult functions can be identified
Disadvantages:
Leads to implementing and then repairing way of building systems. Practically, this methodology may increase the complexity of the system as scope of the system may expand beyond original plans. Incomplete application may cause application not to be used as the full system was designed.
Disadvantages:
Can be a costly model to use. Risk analysis requires highly specific expertise. Project’s success is highly dependent on the risk analysis phase. Doesn’t work well for smaller projects.
When to use spiral process model?
When costs and risk evaluation is important for medium to high-risk projects. Long-term project commitment unwise because of potential changes to economic priorities Users are unsure of their needs. Requirements are complex New product line Significant changes are expected (research and exploration)
(6) Agile Process Model
Agile SDLC model is a combination of iterative and incremental process models with focus on process adaptability and customer satisfaction by rapid delivery of working software product. Agile Methods break the product into small incremental builds. Every iteration involves cross functional teams working simultaneously on various areas like planning, requirements analysis, design, coding, unit testing, and acceptance testing.
Advantages:
Customer satisfaction by rapid, continuous delivery of useful software. Customers, developers and testers constantly interact with each other. Close, daily cooperation between business people and developers. Continuous attention to technical excellence and good design. Regular adaptation to changing circumstances. Even late changes in requirements are welcomed
Disadvantages:
In case of some software, it is difficult to assess the effort required at the beginning of the software development life cycle. There is lack of emphasis on necessary designing and documentation. The project can easily get taken off track if the customer representative is not clear what final outcome that they want. Only senior programmers are capable of taking the kind of decisions required during the development process.
Over view of Software
Agile Process:
Any agile software process is characterized in a manner that addresses a number of key assumptions
[1] It is difficult to predict in advance which software requirements will persist and which will change. It is equally difficult to predict how customer priorities will change as the project proceeds. [2] For many types of software, design and construction are interleaved. That is, both activities should be performed in tandem so that design models are proven as they are created. It is difficult to predict how much design is necessary before construction is used to prove the design. [3] Analysis, design, construction, and testing are not as predictable as we might like.
Agility Principles:
1 Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2 Welcome changing requirements, even late in development. 3 Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4 Business people and developers must work together daily throughout the project. 5 Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6 The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 7 Working software is the primary measure of progress. 8 Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9 Continuous attention to technical excellence and good design enhances agility. 10 Simplicity—the art of maximizing the amount of work not done—is essential. 11 The best architectures, requirements, and designs emerge from self– organizing teams. 12 At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. ope extensions occur).
