Concept of Information Systems and Software : Information gathering, requirement and feasibility analysis, data flow diagrams, process specifications, input/output design, process life cycle, planning and managing the project.
Information Gathering
Information Gathering Strategies
The strategy consists of identifying information sources, evolving a method of obtaining information from the identified sources and using an information flow model of organization.
Information Sources
The main sources of information are users of the system, forms and documents used in the organization, procedure manuals, rule books etc, reports used by the organization and existing computer programs(If Any).
Feasibility Analysis
Feasibility analysis is used to assess the strengths and weaknesses of a proposed project and give directions of activities that shall improve a project and achieve desired results.
Requirements Determination Sub-activities :
- Requirements Anticipation. The systems analyst hypothesizes that particular requirements are relevant based on his or her previous experience with other similar systems and knowledge about the problem domain.
- Requirements Elicitation. The systems analyst uses this activity to gather the essential requirements from the user employing a variety of techniques, such as interviews, questionnaires, group brainstorming meetings, and voice and e mail.
- Requirements Assurance. The systems analyst uses the activity of requirements assurance to validate and verify the requirements with the user as being the real and essential requirements. A user walk through in which the systems analyst and the user together review documented requirements in detail is one assurance technique.
- Requirements Specification. This is the activity that the systems analyst uses to explicitly catalog and document the requirements either during or after the elicitation and assurance activities.
Methods Used To Gather An Information System’s Requirements
Interviews involve at least one systems analyst and at least one user conversing about the information system’s requirements. Interviewing for requirements is similar to your interviewing for a job position or a television talk show host interviewing a guest.
Observation is the act of the systems analyst going to a specific location to observe the activities of the people and machinery involved in the problem domain of interest.
Questionnaires are feedback forms designed to gather information from large groups of people.
Creating a prototype of the information system can be done on an individual level or in a group setting. The idea is to explore system alternatives by developing small working models of the proposed system so that user reactions can be gathered.
System Requirements Specification (SRS)
SRS is obtained after excessive discussions with the user. System requirements specification specifies what Information requirements will be provided. It does not specify how the system will be designed.
Developing A Document Flow Diagram
Example Word Statement
"Our company receives many items from several vendors each accompanied by a delivery note. A receiving office receives the item and checks the delivery note with corresponding order. Any discrepancy is reported to purchase office. The items received along with items received note (with details of items) is sent to the inspection office."
Entities Identified-Vendors, Receiving office, Inspection office
Documents identified - Delivery note, discrepancy note, Items Received note.
Using these a document flow diagram is drawn.
The diagram is interpreted as follows:
- Vendors deliver items to receiving office accompanied by a delivery note.
- Receiving Office sends items to inspection office.
- Receiving office sends discrepancy note to Purchase office.
ENTITIES: Vendor, Receiving office, Inspection office and purchase office
DOCUMENTS: Delivery note, items received and discrepancy note.
Data Flow Diagram (DFD)
DFD has entities and data flows, DFD specifies processing performed by some of the entities. It specifies which entities generate documents and also indicate their flow. Data stores which are referred while processing data and in which processed data may be written or stored are also represented in the Diagram.
- Entities are, originators of data and "consumers" of data.
- Vendor, Inspection office and purchase office are entities in the diagram.
- Data flows are delivery note, items received note and discrepancy note.
- A circle is used to depict a process.
- A pair of parallel lines depict a store.
Input/Output Design
Design Phases
- Architectural design: Identify sub-systems.
- Abstract specification: Specify sub-systems.
- Interface design: Describe sub-system interfaces
- Component design: Decompose sub-systems into components.
- Data structure design: Design data structures to hold problem data.
- Algorithm design: Design algorithms fol problem functions
Coupling
It is the measure of the strength of the interconnections between system components. Loose coupling means component changes are unlikely to affect other components. Shared variables or control information exchange lead to Tight coupling Loose coupling can be achieved by state decentralization (as in objects) and component communication via parameters or message passing. Coupling and Inheritance
Types of Coupling
- Content coupling (high)
Content coupling is when one module modifies or relies on the internal workings of another module (e.g., accessing local data of another module). Therefore changing the way the second module produces data (location, type, timing) will lead to changing the dependent module
- Common coupling
Common coupling is when two modules share the same global data (e.g., a global variable). Changing the shared resource implies changing all the modules using it.
- External coupling
External coupling occurs when two modules share an externally imposed data format, communication
protocol, or device interface.
- Control coupling
Control coupling is one module controlling the flow of another, by passing it information on what to do (e.g.. passing a what-to-do flag). Stamp coupling (Data-structured coupling) Stamp coupling is when modules share a composite data structure and use only a part of it possibly a different part (e.g.. passing a whole record to a function that only needs one field of it). This may lead to changing the way a module reads a record because a field, which the module doesn't need, has been modified.
- Data coupling
Data coupling is when modules share data through, for example, parameters. Each datum is an elementary piece, and these are the only data shared (e.q.. passing an integer to a function that computes a square root).
- Message coupling (low)
This is the loosest type of coupling. It can be achieved by state decentralization(as in objects)and component communication is done via parameters or message passing.(see Message passing).
- No coupling
Modules do not communicate at all with one another.
Software Life Cycle Models
The software life cycle is a general model of the software development process, including all the activities and work products required to develop a software system. A software life cycle model is a particular abstraction representing a software life cycle. Such a model may be:
- activity-centered focusing on the activities of software development
- entity-centered-focusing on the work products created by these activities
Waterfall Model
This prescribes a sequential execution of a set of development and management processes, with no return to an earlier activity once it is completed. Some variants of the waterfall model allow revisiting the immediately preceding activity ("feedback loops") if inconsistencies or new problems are encountered during the current activity.
V-Model
Another variant of the waterfall model-the V-model-associates each development activity with a
test or validation at the same level of abstraction. Each development activity builds a more detailed
model of the system than the one before it, and each validation tests a higher abstraction than its
predecessor
Spiral Model
Spiral model addresses the weakness of the waterfall model, spiral model focuses on addressing risks
incrementally by repeating the waterfall model in a series of cycles or rounds :
- Concept of Operation
- Software Requirements
- Software Product Design
- Detailed Design
- Code
- Unit Test
- Integration Test
- Acceptance Test
- Implementation
Planning And Managing The Project
The SRO, or identifier of the potential project should:
1. Define and justify the need for the project
2. Specify, quantify and agree desired outcome and benefits
3. Appoint a Project Manager and if appropriate set up a Project Board
The project management team should:
1.Plan how to deliver the required outcomes and benefits
2. Decide how to manage relationships with key stakeholders
3. Decide how to project manage the delivery process
4. Determine resource requirements and ensure they can be made available when required SRO/Proiget
5. Develop Business Case to enable the SRO/Project Board to decide whether project is cost and risk justified.
The SRO should ensure:
- Post project reviews are carried out to measure the degree to which benefits have been achieved
- The Business Case is updated to reflect operational reality
- Potential improvements/changes/opportunities identified in the reviews fed into he strategic planning process for consideration
Planning checklist
- Confirm scope and purpose of the plan:
- Define the deliverables:
- Identify and estimate activities
- Schedule the work and resources
- Identify risks and design controls
- Document and gain approval for the plan
Software Estimation
Estimation techniques
Organizations need to make software effort and cost estimates. There are two types of technique that
can be used to do this: Cost is estimated as a mathematical function of product, project and process attributes whose values are estimated by project managers:
Effect = A 'SizeB' M
A is an organisation-dependent constant, B reflects the disproportionate effort for large projects and M is a multiplier reflecting product, process and people attributes.
The most commonly used product attribute for cost estimation is code size Most models are similar but they use different values for A, B and M.
The COCOMO 2 model
Long history from initial version published in 1981 (COCOMO-81) through various instantiations to COCOMO 2 COCOMO 2 takes into account different approaches to software development, reuse, etc.
COCOMO estimation models
Project Formula Description complexity
- Simple PM 2.4 (KDSI) OS X M Well understood applications
- developed by small teams.
- Moderate PM 3.0 (KDSI)12 M More complex projects where
- team members may have limited
- experience of related systems
- Embedded PM 3.6 (KDSI)1 20x M Complex projects where the
- software is part of a strongly
- coupled complex of hardware,
- software, regulations and
- operational procedures.
Application composition model
Based on standard estimates of developer productivity in application (object) points/month.
Formula is
- PM = (NAP (1 - %reuse/100))/ PROD
- PM is the effort in person-months, NAP is the number of application points and PROD is the productivity
Application-point productivity
Based on a standard formula for algorithmic models
- PM A x Size8 x M where
- M = PERS RCPX X RUSE X PDIF x PREX * FCILX SCED
- A = 2.94 in initial calibration, Size in KLOC, B varies from 1.1 to 1.24 depending on novelty of the project, development flexibility, risk management approaches and the process maturity
Reuse model estimates
1. For generated code:
- PM = (ASLOCAT/100)/ATPROD
- ASLOC is the number of lines of generated code
- AT is the percentage of code automatically generated
- ATPROD is the productivity of engineers in integrating this code
2. When code has to be understood and integrated
- ESLOC ASLOC (1-AT/100) AAM
- ASLOC and AT as before
- AAM is the adaptation adjustment multiplier computed from the costs of changing the reused code, the costs of understanding how to integrate the code and the costs of reuse decision making
Post-architecture level
The code size is estimated as:
Number of lines new code to be developed
Scale factors used in the exponent computation in the post-architecture model
Scale factor: Explanation
Precedentedness Reflects the previous experience of the organisation with this type of project. Very low
means no previous experience. Extra high means that the organisation is completely familiar with this
application domain
Development Reflects the degree of flexibility in the development process. Very low means a prescribed
process is used
flexibility Extra high means that the client only sets general goals.
Architecture/risk Reflects the extent of risk analysis carried out. Very low means little analysis, Extra
high means a complete a resolution through risk analysis
Team cohesion Reflects how well the development team know each other and work together. Very low
means very difficult interactions. Extra high means an integrated and effective team with no
communication problems
Process maturity Reflects the process maturity of the organisation. The computation of this value
depends on the CMM maturity Questionnaire but an estimate can be achieved by subtracting the CMM
process maturity level from 5.
Project duration and staffing
Calendar time can be estimated using a COCOMO 2 formula
TDEV = 3-(PM)(033.02 B-1013)
PM is the effort computation and B is the exponent computed as discussed above (Bis 1 for the early
prototyping model). This computation predicts the nominal schedule for the project. The time required is
- independent of the number of people working on the project
Post a Comment
0 Comments