MYTHS
Software management myths
Myth: if we get behind sechedule, we can add more programmers and catch up(sometimes called the “Mongolian horde”concept).
Reality: As new comers are added people who were working must spend time educating the new comers 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: 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 project internally it will invariably struggle when it outsources software projects.
Customer myth
Myth:A general statement of objectives is sufficient to begin writing programes
Reality: Although a comprehensive and stable statement of requirements is not always possible, ambiguous “ statement of objectives” is a recipe for the disaster. Unambiguous requirements usually derived iteratively are developed only through effective and continuous communication between the customer and the developer.
Practitioner’s myths
Myth:Until I get the program “running”I have no way of assessing its quality.
Reality: One of the most effective software quality assurance mechanisms can be applied from the inception of a project. Software reviews are a quality filter that have been found to be more effective than testing for finding certain classes of software defects.
Myth: the only deliverable work product for a successful is the working program.
Reality: a working program is only one part of a software configuration that includes many elements. A variety of work products e.g models, documents, plans provide a foundation for successful engineering and more important for software support.
Myth :software engineering will make us create voluminious and unnecessary documentation and will invariably slow us down.
Reality: software engineering is not all about creating documents. It is all about creating a quality product. Better quality leads to reduced rework. And reduced rework results in faster delivery times.
Software Application Domain Matrix
Domain | Characteristic | Example Software |
System Software | • Generally, programs written to service other programs • Heavy interaction with computer hardware • Heavy usage by multiple users • Concurrent operation that requires scheduling • Resource sharing and sophisticated process management • Complex data structures • Multiple external interfaces | • OS – MS Windows, Linux Ubuntu • Drivers – printer driver • Networking software - wireless networking software • Telecommunication software – messaging system such as sms, mms • Compilers – Borland C++, Turbo C |
Application Software | Used to control business functins in real life time | • Point-of-sale (POS) • Real time manufacturing process control |
• |
Domain | Characteristic | Example Software |
Engineering/Scientific Software | Number of crunching algorithm Ranges from astronomy to volcanology | • Flight simulator |
Embedded Software | Resides within a product Perform limited and esoteric functions | • Software to control robots’ movement • Braking system, dash board displays • Key pad control for a microwave oven |
Production-line Software | Focus on a limited and esoteric market place Provide a specific capability for use by many different customers | • Ms Word • Inventory control products • Spreadsheet • Computer graphics • Database management |
WebApps | Intergrated with corporate database and business application Set of linked hypertext files that present information using text and limited graphics | • Uniten Online Application System |
AI Software | Makes use of nonnumerical algorithms to solve complex problems | • Expert system – Diagnostic Medical expert system • Artificial neutral networks • Theorem proving • Game playing |
No comments:
Post a Comment